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

ab3237b960f24bff8eebd8061360d378.jpg

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

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

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


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

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


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


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

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


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

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


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

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

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

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


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


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

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

Книги по теме


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

© Megamozg