Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Tips for Being a Good Tech Lead»
автора VijayDeveloper.

Лидерство это не услуга, это умение. Профессионалы, работающие разработчиком программного обеспечения в течение нескольких лет, получают шанс стать технологическим лидером. Однако помните, что «с большой силой приходит большая ответственность».

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

10 советов для того, чтобы быть хорошим техническим лидером


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

Помимо руководства командой разработчиков, технический руководитель, как правило, также является тем, кто подбирает людей на собеседовании. Следовательно, вам необходимо знать о самых важных вопросах собеседования при наборе новых членов команды разработчиков.

Быть техническим лидером — это не командовать людьми, а объединять их для достижения успеха. Чем лучше технический руководитель, тем лучше будет команда разработчиков.

Вот 10 советов, которые помогут новичку или опытному техническому руководителю стать лучше в данной роли:

1. Осознание того, что никто не совершенен


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

Ценность и терпение технического лидера проверяются в течение рабочего времени, когда наступает дедлайн, и с членами команды возникают проблемы.

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

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

2. Делегирование важно


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

Неспособность распределить обязанности по широкому кругу вопросов — серьезное препятствие на пути команды. Делегирование — это не командование группой разработчиков, а обдуманное разделение обязанностей.

Чтобы приобрести новые навыки и подняться в рейтинге старшинства, важно взять на себя новые обязанности. Следовательно, делегирование задач членам команды, если все сделано правильно, может быть способом их расширения.

Во время делегирования разрешите членам команды добровольно участвовать в процессе, но не каждый раз. В то время как некоторые из них готовы принять вызовы, другим может не хватить уверенности. Задача технического лидера состоит в том, чтобы мотивировать и подготовить таких участников к принятию решений.

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

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

3. Не будь техническим лидером все время


Быть техническим лидером, очевидно, является вопросом большой ответственности. Однако не нужно вести себя как технический руководитель все время и в любых ситуациях. Некоторые технические лидеры становятся своего рода привратниками и пытаются микроуправлять каждым аспектом функционирования команды.

Разработка программного обеспечения требует команды разработчиков по причине того, что это — сложный процесс. Следовательно, проект не может быть разработан одним человеком. Каждый в команде важен для успеха выполненной работы.

Как и любая материальная вещь в мире, рано или поздно она будет передана другому. Тем не менее, постарайтесь извлечь из этого максимум пользы, когда у существует такая возможность.

4. Уделяйте внимание и время каждому члену команды


Возможно, главное в лидерстве — иметь индивидуальные отношения со всеми членами команды. Для этого необходимо проводить персональные занятия, чтобы связаться с каждым членом команды.

Не нужно следовать режиму один на один, когда вы сидите напротив друг друга в конференц-зале или в кабинете. Вместо этого попробуйте экспериментировать. Возьмите человека на прогулку, поиграйте в игру вместе, выпейте вместе чай или кофе и так далее.

Помните, что обучение — это двунаправленный процесс. У вас учатся не только подчиненные, но и вы также можете научиться у них.

5. Научитесь смотреть шире на обстановку вокруг


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

Вместо этого существуют вещи, которые требуют немедленного внимания, и даже некоторые из них должны быть сосредоточены одновременно. Следовательно, технический руководитель должен часто переключаться между фокусами.

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

6. Учитесь на ошибках и делитесь ими


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

Необходимо быть смелым, чтобы делать ошибки, и скромным, чтобы учиться на них. Важность чего-то, извлеченного из собственного опыта, возрастает, когда им делятся. Следовательно, нужно делиться тем, что вы узнали из своих ошибок, с подчиненными.

Не стесняйтесь делать ошибки. Мы все люди, и поэтому склонны совершать ошибки. Нужно набраться смелости, чтобы принять ошибки, исправить их и сообщить об этом тем, кто найдет ваш опыт полезным. Это способ просветления.

7. Управлять большей частью, а не всем


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

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

8. Подготовьте членов команды для лучшей интеграции в бизнес


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

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

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

Однако в некоторых случаях технический руководитель становится единственным источником связи между технической командой и остальным персоналом нетехнического бизнеса.

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

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

Великие технические лидеры понимают эту ситуацию и поэтому стараются объединить членов технической команды с бизнесом, чтобы избежать вышеупомянутых сценариев. Это легко сделать, приглашая некоторых из них на деловые встречи и приглашая присоединиться к беседе.

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

9. Одинаковое обращение к каждому


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

Несправедливо относиться к одному члену команды с особым отношением, а к другим — как обычно. Лидер не только держит всех вместе, но и поддерживает равенство. Для команды каждый член важен. Вот почему это команда в первую очередь.

10. Средний путь в кодировании


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

Напротив, некоторые новоназначенные технические лидеры отказываются от кодирования. Оба сценария могут быть одинаково вредными. Как правило, разработчики программного обеспечения, которые могут быстро написать качественный код, получают техническую поддержку.

Следовательно, важно сохранять и развивать способность к собственно программированию (кодингу). Техническому руководителю желательно тратить 30 — 60 процентов времени на работу с кодом.

Вывод


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

Комментарии (8)


  1. MixaSg
    02.12.2019 05:41
    +1

    Краткий конспект: делайте как правильно, а как неправильно — не делайте.


    1. shanlove
      03.12.2019 19:15
      +1

      Спасибо, очень помогло!


  1. jetcar
    02.12.2019 11:21

    У меня сейчас немного размазанная позиция, я и архитектор и тех лид и сениор девелопер. В команде кроме меня ещё 1 сениор послабее и несколько аутсорсорсеров из других, но наших офисов, кто-то джуниор, кто-то слабенький джуниор. И я столкнулся с проблемой, что джуниоров ну никак не могу научить писать как надо, мне написать самому быстрее и легче чем им обьяснять. Я конечно понимаю что надо делегировать и их учить, но скорость обучения очень маленькая и они тоже «умные».
    В свою защиту скажу что код и архитектура довольно простые для понимания и они разобрались очень быстро откуда начинать и что делать, но их код уровня универа где пишут так чтоб хоть как-то заработало.
    Позволить им писать как умеют не вариант потому что проект хоть пока и не сильно требователен к перформансу, но нужно постоянно кастомизации встявлять и буквально завтра 100500+ клиентов набежит, поэтому надо писать так как будто у нас они уже есть и учитывать возможные расширения функционала, чтоб не было как в паралельных проектах где надо всё переделать вчера.
    Вот и чё делать не понятно, вроде как я понимаю что надо пытаться выжать максимум из тех ресурсов которые есть, а не надеяться на то что потом наберём получше и всё заиграет, но текущие ресурсы не ускоряют процесс, а наоборот и уже полгода как нет движения в лучшую сторону.


    1. HellMaster_HaiL
      02.12.2019 12:56
      +1

      У вас на двоих сеньоров приходится несколько (я так понимаю минимум двое) джуниоров и один тимлид. В этом, на мой взгляд, и есть проблема. В Вашей команде просто некому писать код. По своему опыту вывел правило, что один джун съедает 50% времени одного сеньора. Два джуна — это уже минус сеньор с проекта.


      1. DimoNj
        03.12.2019 20:53
        +1

        Это какие же должны быть джуны, чтобы на них тратилось по 50% рабочего времени (внимания) сеньора?


        1. HellMaster_HaiL
          04.12.2019 18:16

          и несколько аутсорсорсеров из других, но наших офисов, кто-то джуниор, кто-то слабенький джуниор

          Джуниор джуниору рознь. На практике встречал как и очень толковых старшекурсников, так и уж совсем не пробиваемых, которые не правильно выбрали профессию. К сожалению в команду не всегда попадают люди, которых ты сам можешь отбирать. Встречал таких, которые после универа не понимают в структуры данных и простейшие алгоритмы.
          Работал удаленно, поэтому скрупулезно записывал все время на митинги. Обратил внимание, что на общение с джуниором уходит от 2х часов в день (в случае если человек схватывает) и до 6ти часов (когда приходится работать кувалдой и прочими тяжелыми инструментами). Т.к. уровень подготовки и скилов очередного джуна — это полнейший рандом, то отсюда и обобщил, что
          По своему опыту вывел правило, что один джун съедает 50% времени одного сеньора.



      1. NeverIn
        04.12.2019 19:19

        Совершенно согласен, курирование джунов еще подразумевает переключение контекстов и погружение в задачи начального уровня.


    1. some_x
      03.12.2019 16:45
      +1

      Согласен с предыдущим комментатором, если джуниоров больше 2-х, то это многовато.
      Кроме того, по опыту знаю что иногда у ревьювера может быть синдром «если код написан не так как написал бы я, то это плохой код». Иногда нужно чуть расслабиться и принять, что способов решить задачу много и код не плохой, а просто не привычный.

      Ещё я не понял, привлекаете ли вы сеньёра к review? Если нет, то стоит. Например на задачу назначается два человека: джуниор (который будет делать здачу) и сеньёр который будет его ревьювить. Если потом выясниться что задача сделана косячно, то в первую очередь вопросы к сеньёру.

      Так же, вы пишите что не можете позволить им писать плохой код из-за того потенциальных проблем с производительностью. Почему бы при постановке задачи, вместе с ней не поставлять набор перфоманс тестов для неё? Тогда пусть пишут как угодно, но перфоманс-тесты должны пройти. Если нет времени писать, то можно их же заставить писать такие тесты. Тогда вам нужно будет проверить только корректность тестов.

      Ну и в конце концов если молодой специалист систематически косячит, не прогрессируют (и может быть при этом перечит), то почему бы его просто не уволить?
      К этому надо относиться спокойно. Должность младшего специалиста это фильтр который не все проходят.