В нашем блоге на Мегамозге мы много пишем об интересных подходах к менеджменту (которые стараемся применять в работе над облачным сервисом 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
На сегодня все, спасибо за внимание! В комментариях пишите ваши советы по переквалификации из разработчика в руководителя.
Автор: 1cloud.ru
