В нашем блоге на Мегамозге мы много пишем об интересных подходах к менеджменту (которые стараемся применять в работе над облачным сервисом 1cloud) и интересных способах решения проблем, с которыми сталкиваются ИТ-компании.
Одна таких сверхпопулярных проблем — переход хорошего технического специалиста от роли исполнителя к должности руководителя (например, тимлида). В нашем сегодняшнем материале мы собрали некоторые советы и ссылки на книги по теме, которые были опубликованы в соответствующем треде на HackerNews.
Делать грязную работу нужно самому
Пользователь под ником 7402 вывел три правила хорошего технического руководителя. Вот, как они звучат:
- Если есть выбор между интересной задачей и чем-то непонятным и непривлекательным, то хороший техлид должен передать интересную задачу подчиненному, а самому заняться грязной работой.
- Если кто-то из членов команды хочет задать вопрос, хороший руководитель должен быть всегда доступен для этого (и не стоит делать недовольное лицо в стиле «опять меня отвлекают»). Но если самому руководителю нужно задать кому-то вопрос, то он сперва должен поинтересоваться, не сильно ли это отвлечет сотрудника. Не нужно выводить подчиненных из состояния потока.
- Если кто-то из членов команды высказал идею, которая не кажется руководителю хорошей, не нужно впрямую критиковать ее (как можно было бы поступить, будь он все еще разработчиком). Нужно сказать что-то типа «Не думаю, что это сработает, но наверняка же не скажешь. Сколько времени у вас уйдет на более подробную проработку вопроса?» В условиях жестких дедлайнов такой подход сложно применить, но если вам в компании нужны хорошие инженеры, то в долгосрочной перспективе это полезно.
Код вместо встреч
Другой пользователь HackerNews под ником Jackrabbit1981 считает, что главной задачей тимлида является поддержание эффективности работы членов команды. А это значит, что:
- Тимлид должен знать код — вместо встреч время лучше потратить на программирование.
- Не нужно стесняться указывать на ошибки — даже если в результате кому-то придется переделать кучу работы. Но не нужно стараться быть умнее, чем это на самом деле — если руководитель чего-то не знает, признаться в этом совсем незазорно.
- Вести за собой подчиненных нужно личным примером — если тимлид пишет «говнокод» и берется только за легкие и красивые задачи, то что спрашивать с остальных?
- Код тимлида должен проходить ревью на равне с тем, что написали другие члены команды.
Роль тимлида не значит, что занимающий ее человек чем-то лучше остальных. Он такой же как все, его работа в том, чтобы помогать остальным членам команды, а уважение ее членов еще нужно заслужить.
Важно держать в уме цели бизнеса
Пользователь hndl, в свою очередь, предлагает начинающему техническому руководителю сконцентрироваться на выработке общего видения. Разработчики живут кодом, но их руководитель должен понимать, как этот код в конечном итоге поможет бизнесу.
Это, помимо прочего, позволит ему не только лучше направлять усилия членов команды, но и на должном уровне защищать ее в обсуждениях с другими руководителями — возможно, какая-то из предлагаемых фич не так уж и много даст компании, а на ее разработку и тестирование уйдет уйма времени.
Кроме того, есть и несколько вещей, которые только что назначенный технический руководитель не должен делать ни в коем случае.
- Нельзя ругать код, который написан до этого момента — никому не понравится услышать такое о своей работе от нового человека прямо с порога.
- Работать с техническим долгом нужно поэтапно. Нельзя просто взять и потребовать «переписать XYZ».
- Не стоит предлагать перейти на альтернативные фреймворки и платформы. Раз в разработке они раньше не использовались, то скорее всего, члены команды не очень хорошо с ними знакомы.
Инициативы улучшения должны исходить не только от подчиненных
Технический руководитель проекта больше всех заинтересован в том, чтобы его архитектура была продуманной, а код — качественным, считает пользователь arnonejoe. Это значит, что руководитель должен продвигать внедрение признанных механизмов, помогающих улучшить качество работы — например, логирование или инструментацию кода.
Кроме того, не стоит забывать и о базовых вещах, вроде объяснения того, как правильно писать юнит-тесты — часто джуниор-программисты этого не знают. Сюда же относится и постоянное проведение ревью кода и работа с техническим долгом. Ну и нужно «пробить» для членов команды лицензии на ReSharper.
Книги по теме
Помимо собственных советов участники дискуссии на HackerNews привели большое количество ссылок на полезные книги по теме управления проектами и разработки качественного кода. Мы приводим ссылки на них as is, то есть на английском языке — это не должно быть проблемой для современных технических руководителей:
- The Mythical Man Month
- Peopleware: Productive Projects and Team
- The Pragmatic Programmer
- Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams
- Joy Inc: How We Built a Workplace People Love
- A Lapsed Anarchist's Approach to Being a Better Leader
- Becoming a Technical Leader: An Organic Problem-Solving Approach
- Code Complete
- Leading Snowflakes
- The Psychology of Computer Programming
На сегодня все, спасибо за внимание! В комментариях пишите ваши советы по переквалификации из разработчика в руководителя.
Комментарии (15)
balamut108
22.10.2015 15:05+1Вопрос только, зачем переходить в руководители, терять квалификацию, если ведущий разраб в среднем получает столько сколько ПМ.
ncix
22.10.2015 16:33Не все решают деньги. А если просто хочется? Мне кажется это единственная существенная причина (конечно при наличии такой возможности). Переходить в руководители против собственного желания конечно не нужно.
balamut108
22.10.2015 16:38Руководить людьми это не самое приятная задача, я бы не советовал…
ncix
22.10.2015 16:41Согласен. Но не попробуешь — не узнаешь. Если есть желание — нужно обязательно искать такую возможность.
Всегда лучше сделать и ошибиться, чем не сделать и всю жизнь себя пилить неопределенностью «а вот если бы я тогда...».
YuppY
22.10.2015 22:56Вот хороший ответ на аналогичный вопрос: habrahabr.ru/company/payonline/blog/268325/#comment_8617761
Если вкратце, то смысл в расширении сферы влияния и власти. На руководящей должности можно реализовать столько интересных задумок, сколько не под силу даже самому крутому ведущему разработчику.
NeverIn
23.10.2015 16:55На мой взгляд руководители вырастают не из первоклассных разработчиков. Скорее из QA или Product Owner/Manager.
Т.к. тут требуется несколько иные скиллы, чем виртуозное владение байтами. Хотя и наличие технических знаний очень важно.
Нужно иметь соответствующий склад характера, а разработчики в большинстве своем интроверты.
Да и по деньгам выигрыша не наблюдается на рынке, а трудоустроиться разработчику проще.balamut108
23.10.2015 17:23Мировой тренд — сокращение управленческих кадров. Так что не рекомендую, хотя я сам руководитель и сейчас ухожу больше в разработку.
ncix
22.10.2015 16:30+1Если кто-то из членов команды хочет задать вопрос, хороший руководитель должен быть всегда доступен для этого
Верно, только руководителю стоит всегда думать — а не сможет ли исполнитель сам ответить на свой вопрос? Если так, то не нужно его «отфутболивать». Даже если вы сейчас читаете «Мегамозг», сделайте очень сосредоточенное лицо, и предложите поговорить об этом через полчаса. Через полчаса сотрудник в половине случаев сам решит эту проблему, проверенно на собственном опыте.
Если же кидаться решать все подряд вопросы — сотрудники просто потеряют напрочь инициативу. Они будут спрашивать у вас общедоступную информацию и задавать совершенно юниорские вопросы, просто потому что считают что так и нужно. Развивайте инициативу в своих сотрудниках!
ncix
22.10.2015 16:36Важно держать в уме цели бизнеса
Если мы говорим о руководителях уровня тимлидов, то бизнес это совсем не их уровень компетенции.
ncix
22.10.2015 16:38Технический руководитель проекта больше всех заинтересован в том, чтобы его архитектура была продуманной, а код — качественным, считает пользователь arnonejoe. Это значит, что руководитель должен продвигать внедрение признанных механизмов, помогающих улучшить качество работы — например, логирование или инструментацию кода.
Руководитель должен прежде всего думать о приоритетах конкретного проекта. Если есть время и ресурсы — конечно стоит подумать об инвестициях в будущее в виде глубокого рефакторинга и внедрения новых инструментов.
Если «сроки горят» нужно иметь смелость настаивать на быстрых решениях.
Joenah
22.10.2015 22:38+1А вот история о том, как бармен сначала стал разработчиком, потом ушел в проджект-менеджмент: dou.ua/lenta/interviews/barman-project-manager
mckalech
А что почитать на русском?
Ad_Astra
«Мифический человеко-месяц» точно есть в электронке на Books.ru в переводе (hint: а ещё там периодически бывают распродажи ;)).