Что такое быть тимлидом / Хабр

Что такое быть тимлидом / Хабр Должностные инструкции

Два небольших примера из моей практики

В компании, где я работал, был фиксированный график, разработчики должны были приходить в 11 и уходить не раньше 8, но был один программист, который постоянно выхватывал от меня за то, что приходил на 10-20 минут позже (кстати, это тоже работа тимлида, дрочить людей за такие вещи) и всегда ныл на тему того, что далеко живет и не всегда может оценивать время потраченное на дорогу.

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

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

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

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

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

В конечном итоге ты научишься оценивать риски, и научишься работать с ними, будешь задумываться о таких вещах, о которых ты раньше не знал ровным счетом ничего. Тут проще объяснить на примере: вы на следующей неделе начинаете с нуля разрабатывать какую-нибудь новую штуку, к тебе приходит пара твоих подчиненных и говорят — «А давай начнем это писать на котлине».

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

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

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

Поэтому тебе придется научиться говорить “нет” и объяснять почему нет. Иногда ты должен будешь зарубить инициативу на корню. Любая инициатива должна поддерживаться сверху, иначе она заглохнет или принесет только проблемы. Не важно, какие поступают предложения — сменить марку кофе, заказываемую в офис, или устаревшую технологию, выбрать новый модный фреймворк или язык программирования.

Если предложение неуместно на данный момент и ты можешь объяснить почему, или, как иногда бывает, оно совершенно идиотское, то об этом надо сказать сразу же, без всяких «Мы подумаем», «Необходимо будет обсудить» или «Может быть». И уж тем более без слов: «Бери флаг в руки, а мы подхватим, но чуточку позже, например через месяц».

Другие инструкции:  Должностная инструкция обойщика мебели 4-го разряда

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

Лучше сразу решительно сказать: «Нет, этого не будет никогда» или «Извини, но в данный момент это предложение не уместно, но мы можем попробовать поговорить об этом через 3-6-12 месяцев», (понятно, что, скорее всего, никто не будет возвращаться к этому разговору), чем позволить человеку погрузиться в мир иллюзий, возвращение из которого крайне болезненно.

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

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

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

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

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

В какой-то момент, ты узнаешь, что все изменения следует мониторить, по ним следует собирать фидбек, как они повлияли, были ли изменения позитивными, может стоит вернутся на пару шагов назад и попробовать что-то другое? Потому что оно не работает. Конкретно для тебя и твоей команды.

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

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

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

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

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

И с этого момента люди начнут тебе доверять, они не будут считать тебя начальником, они начнуть тебя считать лидером, и смогут дать необходимый фидбек, который очень тяжело собрать другим путем. Они откроются тебе. Кто-то часто ходит по вечерам в паб посидеть с пивом (алкоголь слегка развязывает язык), кто-то находит общие увлечения и может делится своим взглядом.

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

Другие инструкции:  "Методические рекомендации по созданию школьных спортивных клубов общеобразовательных организаций"(утв. Минпросвещением России 28.09.2021 N 06-1400)

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

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

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

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

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

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

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

И четвертое, самое главное — сомневаешься в выборе, не бери. Ты никогда не должен сомневаться. Любые сомнения должны конвертироваться в четкое «нет». Этот совет сохранит тебе кучу времени и нервов.

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

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

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

И да, иногда ты будешь писать код. Если у тебя будет хватать времени на это. А иногда ты будешь это делать, даже если времени у тебя не хватает.

Кто такой тимлид и как им стать с нуля в 2021 году

Обязанности тимлида

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

В перечень основных обязанностей тимлида входит:

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

Определение должности тимлида

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

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

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

  1. Стажер.
  2. Junior (новичок).
  3. Middle (средний уровень).
  4. Senior (высокий уровень, сложные задачи, самостоятельная работа).
  5. Team lead (руководитель команды, постановщик задач).

Тимлид — это англицизм, произошедший от словосочетания team lead (leader). Прямой его перевод: ведущий команды, лидер команды.

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

Грубо говоря, люди являются его инструментами, и в случае неудовлетворительного результата ответственность нести будет именно “мастер”, а не “инструменты”, которыми он работал.

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

Размещение вакансии

Расскажу историю про один американский проект, с которым мы работаем — это сервис по доставке парфюма по подписке в США. Компания называется Scentbird, раньше их на российском рынке практически никто не знал. Им нужны были Java-разработчики. Мы могли написать:

Что такое быть тимлидом / Хабр
Что такое быть тимлидом / Хабр
Что такое быть тимлидом / Хабр

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

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

Требования работодателя

Для работодателя важна эффективность и качество выполняемой работы. Ему нужен надежный человек, который может самостоятельно решать мелкие проблемы, которому можно было бы доверить проект.

Для этого специалист должен обладать такими личностными качествами, как:

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

До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:

  1. Аналитические способности.
  2. Знания серверных технологий.
  3. Готовность к самообучению.
  4. Умение учитывать мнение команды.
  5. Знания масштабируемости веб-проектов.
  6. Способность принимать быстрые и простые решения в стрессовых ситуациях.
  7. Умение распределять обязанности внутри коллектива.
  8. Навыки и умения в программировании на уровне senior.
  9. Оценка и планирование бюджета.
  10. Умение рассматривать проблему с разных ракурсов.
  11. Навыки наставничества.
  12. Умение нести ответственность за работу других людей.
  13. Знания языков программирования.
  14. Способность учитывать риски.
  15. Умение заметить и исправить ошибку.
  16. Знания планирования задач.
  17. Умение планировать, ставить сроки и укладываться в них.
  18. Способность сформировать команду, обучать и мотивировать новых сотрудников.
  19. Умение переработки требований заказчика в техническое задание.
  20. Знания в области психологии, социологии, менеджмента и кадровой политики.
  21. Навыки решения конфликтов и поддержания рабочей мирной атмосферы.
  22. Умение распределять нагрузку между членами группы.
  23. Знания ведения переговоров.
  24. Умение проводить тестирование готового продукта.
  25. Навыки контроля всех этапов работы.
  26. Умение вести документацию.

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

Оцените статью
Добавить комментарий