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

В нашем блоге на Мегамозге мы много пишем об интересных подходах к менеджменту (которые стараемся применять в работе над облачным сервисом 1cloud ^[1]) и интересных способах решения проблем, с которыми сталкиваются ИТ-компании.

Одна таких сверхпопулярных проблем — переход хорошего технического специалиста от роли исполнителя к должности руководителя (например, тимлида). В нашем сегодняшнем материале мы собрали некоторые советы и ссылки на книги по теме, которые были опубликованы в соответствующем треде ^[2] на HackerNews.

Делать грязную работу нужно самому

Пользователь под ником 7402 вывел три правила хорошего технического руководителя. Вот, как они звучат:

1. Если есть выбор между интересной задачей и чем-то непонятным и непривлекательным, то хороший техлид должен передать интересную задачу подчиненному, а самому заняться грязной работой.
2. Если кто-то из членов команды хочет задать вопрос, хороший руководитель должен быть всегда доступен для этого (и не стоит делать недовольное лицо в стиле «опять меня отвлекают»). Но если самому руководителю нужно задать кому-то вопрос, то он сперва должен поинтересоваться, не сильно ли это отвлечет сотрудника. Не нужно выводить подчиненных из состояния потока.
3. Если кто-то из членов команды высказал идею, которая не кажется руководителю хорошей, не нужно впрямую критиковать ее (как можно было бы поступить, будь он все еще разработчиком). Нужно сказать что-то типа «Не думаю, что это сработает, но наверняка же не скажешь. Сколько времени у вас уйдет на более подробную проработку вопроса?» В условиях жестких дедлайнов такой подход сложно применить, но если вам в компании нужны хорошие инженеры, то в долгосрочной перспективе это полезно.

Код вместо встреч

Другой пользователь HackerNews под ником Jackrabbit1981 ^[3] считает, что главной задачей тимлида является поддержание эффективности работы членов команды. А это значит, что:

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

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

Важно держать в уме цели бизнеса

Пользователь hndl ^[4], в свою очередь, предлагает начинающему техническому руководителю сконцентрироваться на выработке общего видения. Разработчики живут кодом, но их руководитель должен понимать, как этот код в конечном итоге поможет бизнесу.

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

Кроме того, есть и несколько вещей, которые только что назначенный технический руководитель не должен делать ни в коем случае.

1. Нельзя ругать код, который написан до этого момента — никому не понравится услышать такое о своей работе от нового человека прямо с порога.
2. Работать с техническим долгом нужно поэтапно. Нельзя просто взять и потребовать «переписать XYZ».
3. Не стоит предлагать перейти на альтернативные фреймворки и платформы. Раз в разработке они раньше не использовались, то скорее всего, члены команды не очень хорошо с ними знакомы.

Инициативы улучшения должны исходить не только от подчиненных

Технический руководитель проекта больше всех заинтересован в том, чтобы его архитектура была продуманной, а код — качественным, считает пользователь arnonejoe ^[5]. Это значит, что руководитель должен продвигать внедрение признанных механизмов, помогающих улучшить качество работы — например, логирование или инструментацию кода.

Кроме того, не стоит забывать и о базовых вещах, вроде объяснения того, как правильно писать юнит-тесты — часто джуниор-программисты этого не знают. Сюда же относится и постоянное проведение ревью кода и работа с техническим долгом. Ну и нужно «пробить» для членов команды лицензии на ReSharper.

Книги по теме

Помимо собственных советов участники дискуссии на HackerNews привели большое количество ссылок на полезные книги по теме управления проектами и разработки качественного кода. Мы приводим ссылки на них as is, то есть на английском языке — это не должно быть проблемой для современных технических руководителей:

• The Mythical Man Month ^[6]
• Peopleware: Productive Projects and Team ^[7]
• The Pragmatic Programmer ^[8]
• Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams ^[9]
• Joy Inc: How We Built a Workplace People Love ^[10]
• A Lapsed Anarchist's Approach to Being a Better Leader ^[11]
• Becoming a Technical Leader: An Organic Problem-Solving Approach ^[12]
• Code Complete ^[13]
• Leading Snowflakes ^[14]
• The Psychology of Computer Programming ^[15]

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

Автор: 1cloud.ru

Источник ^[16]