Перевод статьи «Leadership is not made of code».
Руководитель команды (тимлид) это ключевая фигура в команде разработчиков. Это сложная роль, требующая как технических навыков, так и навыков работы с людьми. Вот почему эта позиция не каждому по плечу.
Техническая компетентность обычно не является проблемой (подчеркнем – обычно). Другое дело навыки работы с людьми и лидерские качества (назовем их в совокупности лидерством). Технические навыки имеют первостепенное значение, это основа всего, но умение вести за собой строится не на этой основе. Лидерство это нечто, что держит команду вместе и мотивирует ее членов.
Плохое руководство может поставить под сомнение не только успех продукта, но и существование самой команды. Не такой редкий случай, когда хорошие разработчики уходят из-за плохого тимлида (т. е., босса). Так что к этому не стоит относиться легкомысленно.
Итак, что же такое лидерство на на чем оно основано?
В основе лидерства лежит уважение
Уважение это ключевой момент в лидерстве. Хорошего тимлида должны уважать другие разработчики, и в первую очередь – как профессионала. Тяжело уважать человека, которого не считаешь достаточно квалифицированным. Но как уже говорилось, лидерство это не только техническая компетентность. Это значит, что тимлида должен пользоваться уважением как личность. Как этого достичь? Ответ прост: если вы хотите заслужить уважение, вы должны уважительно относиться к окружающим.
Уважение это дорога с двусторонним движением
Вам случалось чувствовать, что вы не нравитесь своему боссу? Что на самом деле вы не являетесь частью команды? Что все, что вы делаете, недостаточно или неправильно? Подобные ощущения приводят к тому, что разработчики не раскрывают в полной мере свой потенциал. Также эти чувства способствуют отсутствию уважения к начальству. Если я чувствую, что я тебе не нравлюсь, вероятно, в конце концов ты мне тоже не будешь нравиться.
Отсутствие предубеждений
Разработчики это прежде всего люди. У них есть свои достоинства и недостатки, у них есть жизнь и семья вне офиса. Тимлид должен уважать разработчиков и как профессионалов, и как людей. Он должен относиться ко всем одинаково, без предвзятости. Личные чувства следует оставлять за порогом офиса. Это сложно, но хороший тимлид с этим справляется.
В основе лидерства лежит доверие
Доверие это основа любых отношений, и профессиональные – не исключение. Лидерство означает доверие к разработчикам.
Твой путь это не мой путь
Лично я ненавижу, когда босс не только говорит мне, что нужно сделать, но и подробно указывает, как именно я должен это делать. Еще хуже, если он постоянно стоит где-то у меня за спиной, проверяя, что я делаю и как я это делаю. Естественно, в таких обстоятельствах я приду к выводу, что босс мне не доверяет. В конечном итоге я начну больше беспокоиться о том, чтобы решить задачу именно так, как сказал босс, а не наилучшим способом (да, эти два пути порой не совпадают).
Делегирование полномочий полезно всем
Вот почему важно, чтобы тимлид доверял разработчикам. Нужно реализовать новый функционал продукта? Выберите пару разработчиков и дайте им возможность сделать это самим, от дизайна до отправки в производство. Узнавайте периодически, как у них обстоят дела, давайте советы при необходимости, но предоставьте свободу работать самостоятельно.
Делегирование задач показывает вашу уверенность, что разработчики сделают свое дело хорошо. Вы сможете сосредоточиться на картине в целом, не отвлекаясь на реализацию деталей. Они будут благодарны вам и постараются сделать все в лучшем виде. И волки сыты, и овцы целы.
В основе лидерства лежат правила
Правила это то, благодаря чему функционирует наше общество. То же самое касается команды разработчиков. Каждый руководитель может создать свод правил и представить его команде. Но именно лидерство заставляет членов команды следовать этим правилам, потому что они хотят им следовать, а не потому что обязаны. Это возможно только в том случае, если люди верят, что лидер создает свод правил на основе их общих ценностей (доверия и уважения).
Навязанные правила это не правила
Не знаю, как вы, а мне бывало очень тяжело следовать правилам, в которые я не верил. Я не могу делать что-то лишь потому, что кто-то мне сказал делать именно так, без объяснений или, как минимум, обсуждений. Я, конечно, попытаюсь следовать подобным правилам, но скорее всего отброшу те, которые посчитаю ошибочными. Если каждый в команде будет делать так же, в результате правил у вас не останется. Попрощайтесь с продуктивностью.
Находим общий язык
Даже если последнее слово за вами, тимлидом, обсудите правила с командой. Таким образом у вас будет общее поле для деятельности. Больше никаких отклонений от правил. Под правилами может подразумеваться что угодно, от стандартов написания кода до выбора IDE. Что-то может казаться вам тривиальным, но лучше обсудить даже мелочи. При этом тимлид должен показывать всем пример и быть первым, кто всегда следует установленным правилам.
В основе лидерства лежит время
Тимлид должен ценить время разработчиков – самое важное, что они могут дать команде. Поэтому избегайте ненужных собраний. Но если разработчик просит уделить ему время, тимлид должен это сделать.
Мое время столь же ценное, как и ваше
Я понимаю, что все всегда заняты. Но если я попросил вас, тимлида, поговорить со мной, потому что мне это нужно по какой-то достойной причине, и вы назначили личную встречу, я ожидаю, что вы на нее придете. Мое время имеет ту же ценность, что и ваше. И если вы не уважаете мое время, это плохо. Во-первых, вы заставляете меня ждать и зря терять свое время. Вместо этого я мог бы сделать что-то полезное. Во-вторых, это вызывает ощущение, что я не стою вашего времени.
Отводите время для общения с разработчиками
Введите в обиход регулярные собрания для обсуждения текущего положения дел в проекте. Найдите время ежемесячно поговорить с каждым разработчиком с глазу на глаз, чтобы узнать, как у него дела и разобраться в его потребностях. Назначая встречу, всегда приходите на нее вовремя. Помните простое правило:
- Прийти на пять минут раньше значит прийти вовремя.
- Прийти вовремя значит опоздать.
- Опоздание неприемлемо.
Я уже это говорил, но повторюсь: тимлид всегда должен показывать пример.
В основе лидерства лежит сила
Порой дела идут хуже некуда. Когда такое происходит, тимлид должен оставаться сильным.
Когда все начинает рушиться…
Если вы тимлид, то вы в любой ситуации должны быть эталоном. В том числе, когда что-то идет не так, как задумано. В противном случае вы можете вызвать цепную реакцию, из-за чего команда потеряет способность разрешить проблемную ситуацию. В худшем случае из-за вашей неспособности справиться с происходящим обвинят ваших разработчиков. И если вы неспособны разруливать проблемы, то, весьма вероятно, просто не подходите на роль тимлида.
Не паникуйте
Лидерство подразумевает силу и способность всегда быть опорой для разработчиков, даже если Армагеддон на носу. Если разработчики увидят, что вы паникуете и теряете контроль над ситуацией, они тоже поддадутся панике. А это последнее, что вам нужно в сложной ситуации. Паника не решает проблемы. Поэтому сделайте себе и своим разработчикам одолжение: сохраняйте спокойствие. Не паникуйте.
Заключение
Роль тимлида сложная, она требует как технических, так и социальных навыков. Вам нужно быть компетентным в технических вопросах, но этого недостаточно, чтобы быть хорошим тимлидом. Создание продуктивной и сплоченной команды имеет и другие, более важные аспекты.
Напоследок замечу, что главный фокус в том, чтобы постоянно думать о благе вашей команды. Ведь, в конце концов, тимлид работает на разработчиков, а не наоборот.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]