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

    Интро


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


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


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


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


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


    На самом деле лиды не должны уметь фейлить, они должны уметь делегировать свои фейлы, как и все остальное (сарказм).


    Что изменится


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


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


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


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


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


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


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


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


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


    Потому что в конечном итоге ты станешь единой точки ответственности и компетенции команды.


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


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


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


    Ты должен будешь научиться делегировать. И задачи, и ответственность. Это тебя разгрузит и позволит выполнять свои обязанности гораздо лучше. Более того, если ты не научишься делегировать, ты просто не справишься с ростом.


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


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


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


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


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


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


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


    В конечном итоге ты научишься оценивать риски, и научишься работать с ними, будешь задумываться о таких вещах, о которых ты раньше не знал ровным счетом ничего. Тут проще объяснить на примере: вы на следующей неделе начинаете с нуля разрабатывать какую-нибудь новую штуку, к тебе приходит пара твоих подчиненных и говорят — "А давай начнем это писать на котлине". В твоей голове начинают рождаются множество вопросов. Во-первых хватает ли у нас экспертизы для того, чтобы начать писать новую вещь (а она может быть очень критичной для бизнеса), на новом языке с недостаточной экспертизой команды.
    А что мы будем делать, если через полгода эти ребята уволятся. Как и сколько времени мы будем искать новых людей, которые имеют необходимую экспертизу для дальнейшей разработки.
    А не получится ли так, что на данном проекте мы увеличим bus factor, потому что все остальные ребята не хотят сейчас переходить на котлин, и не имеют экспертизы в нем.
    А сколько дополнительного времени нам стоит заложить, потому что факапы будут, причем самое страшное, что мы не знаем какие именно. Но они будут.
    А сможем ли мы с этими двумя ребятами сделать все правильно, в срок, обучив другую часть команды. Подхватят ли этот энтузиазм остальные.
    А нужно ли это нам именно сейчас, когда все бегают с горящими жопами.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


    Если кратко


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


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


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


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


    Что делать то


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


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


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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 48

      +7
      Нет чёткого описания обязанностей стандартного тимлида, какие они?
      А в описании присутствует очень много функций от ПМ и архитектора. Прямо комбайн, и финансы посчитай, и сопели протри и технологии выбери :)
        +1
        Ага, ещё и код пиши.
            0
            Почитал, поудивлялся.
            Описаны все функции ПМа на проекте :)
            Оно и не странно… список профессий на этом сайте это сбор SEO текста, есть чудные отраслевые профессии Линк-менеджер и Специалист по информационным системам…

            Если у человека в обязанностях стоит:
            — заключение договора с клиентом;
            — ведение договоров и других документов;
            — оценку объёмов, бюджета и планирование сроков работ;

            То он практически автоматом уже не может заниматься технической частью проекта как программист, как архитектор и т.д., ну не будет у него сил и времени даже на небольших проектах.
              0
              скорее да, сложно точно ограничить зону работы. Во многом зависит от возможностей компаний, разумности руководства. Да и в целом нигде нет талмута, который как 2+2 обозначил рабочие обязанности. Даже нет четких ограничений между senior и middle или middle и junior. Есть только размытые трактовки.
                –1
                Да всё довольно чётко.
                Тимлид (как программист) управляет группой разработчиков для достижения какой-то цели, разбирается в деталях разработки.
                Джунион — ему всё надо рассказать как делать и проконтролировать.
                Мидл — ему надо в общих чертах рассказать как делать и проконтролировать.
                Сеньор — ему надо объяснить понятно что надо делать и всёравно проконтролировать.
                  0
                  Ваше определение тимлида чем отличаются от техлида?
                  Ваши определения уровней разработчиков не кажутся ли размытой? Нет четкой грани разделения ). Они не отвечают на вопросы выбора уровней сложности назначаемых задач, скорости их реализации, выгодно ли это в итоге бизнесу(грубо говоря стоит ли набирать джунов, мидлов, может только сеньеров)
                    0
                    Техлид это же вообще не должность, а «звание» :)
                    Нет чёткой грани?
                    Она есть — если всё разжовано, то и джуниор сделает сложную задачу (если не сделает то нафиг вообще такого программиста).
                    Если недостаточно разжовано, то мидл может быть сделает задачу :)
                    Сениор же должен сделать полюбому, как ни крути или сказать что все дураки :)

                    Для бизнеса тоже всё чётко получается… главное чтобы кто-то от бизнеса умел «варить» программистов :)
                    Если у бизнеса есть тот кто будет жевать для джуниоров, если ему есть куда приткнуть джуниоров, чтобы они дешево выполняли финансово затратные задачи, то бери пожалуйста…
                    Если жевать за них некому, но есть кто-то кто может водить за собой мидлов, и по срокам мидлы укладываются, или если финансирование разработки не может сразу выложить сто тыщ мильёнов, то мидлы вполне для вас :)
                    Если у вас есть деньги и жгучее желание сделать быстро и хорошо, то сеньоры ваш единственный вариант.
                      0
                      Можете провести исследование. Перешлите ваши понятия человеку не в теме, поймет ли он вас )
                        0
                        Какое исследование? Зачем нам кто-то не в теме?
                        Статья для тех кто в теме :)
                        Вы так и не ответили про какого вы заказчика, на проекте можно много людей назвать заказчиками.
          +3
          мне приходилось заниматься этим всем, совместно и с проджектом, и с продуктом. Ну и очень часто тимлид, это еще подразумевает то, что ты будешь еще и техлидом. Но опять же, зависит от компании, подходов и размера команды
            0
            Так вот вы не написали, вы про тимлида-программиста или про тимлида-менеджера?
            Первому я бы финансы даже не подумал делегировать, второму же лезть в технические детали не позволил.
            Мне тоже приходилось заниматься всем, причём во все концы.
              –2
              Тимлид разработчиков — мост между миром менеджеров и разработчиков. Его цель доносить мысль управленцев, заказчиков до команды в том виде, как они лучше понимают. Мышление у всех разное ). А также наоборот, объяснять заказчикам технические нюансы его требований на понятном ему языке.
                +1
                Тимлид не мост, он организует работу группы программистов.
                Менеджеру какая разница какому из N программистов говорить куда копать? Менеджер сказал куда копать — дальше программист «дурак» :)
                Менеджеру накладно каждому из N программистов рассказывать куда им копать индивидуально!
                Вот тимлид и появляется…

                «объяснять заказчикам технические нюансы» — вся проблема дискуссий под статьёй из-за того, что понятия все в слова вкладывают разные.
                Это вы про какого заказчика тут? Боже упаси тимлида в общем случае пускать рассказывать что-то внешнему заказчику!
                Вы наверное про внутреннего заказчика? Про менеджера того самого :) Ну да, менеджеру стоит сразу сказать кто «дурак» если такой факт есть :)
              0

              И дайте угадаю, за одну зарплатную ставку, да?

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

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

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

                Но опять же, есть и те, кто просто таски из столбца в столбец перекидывают, на совещания ходят и смотрят, что бы каждый фаллосы не пинал в рабочее время.
                  0
                  Вот вы описали обычного тимлида — вместо того чтобы менеджерам гонять и получать фидбек от 3-10 программистов, они гоняют одного тимлида. Он для этого и нужен, он должен понимать зачем его «создали» :)
                  Если в компании уже есть потребность в тимлиде, то функции ПМ и архитектора вероятнее всего тоже найдется кому выполнять.
                  Не спрашивают с обычного тимлида за все провалы по проекту и за финансовое планирование.
              +1
              Это у линейных сотрудников есть чёткое описание обязанностей. Чем выше должность — тем больше в ваши обязанности входит всё то, что не входит в обязанности ваших подчинённых. Иногда что-то можно делегировать, а иногда просто нет человека со схожим функционалом и кто-то должен это делать. На топ-уровне оцениваются не обязанности, а результаты, сделанные продукты, урезанные расходы, полученная выручка и т.п., и не так важно, что именно вы делали для этого.
                0
                Чем выше должность — тем чётче описаны обязанности, т.к. «ответственность» выше.
                Причём тут уровень топ менеджеров и тимлид? Вы про какую оргструктуру? Тимлид это должность под ПМ, CTO или руководителя отдела.
                Вы пишите что тимлид ответственнен за продукт? И тимлид расходы по проекту можер урезать?
                  0
                  Я нигде не употреблял слово тимлид и говорил о более общем принципе.
                  Касательно вашего первого тезиса, давайте тогда определим, что понимать под обязанностями. Я понимаю некоторый неизменный функционал, часто хорошо стандартизованный и описанный. По моему опыту чем выше должность, тем большую роль играют не обязанности, а цели на квартал, полугодие, другой период. Кроме того, большую часть работы составляет то, что предугадать и описать просто невозможно. Если для линейных сотрудников можно написать какие-то правила как действовать в непонятных ситуациях, то для их руководителя во-первых не очевидных ситуаций становится в 10 раз больше за счёт большего фронта работы и эскалации вопросов от подчинённых, а во-вторых отсутствует экспертиза по их решению. Как ген директор может хорошо прописать обязанности CTO, если его зона экспертизы это продажи (что чаще всего бывает), а не технологии. В лучшем случае будут средней степени проработки KPI, а в остальном от человека требуется проактивность и здравый смысл. С тимлидами ситуация конечно проще, так как часто его руководитель сам бывший тимлид, но он может быть тимлид бекенда, а нужно управлять тимлидом мобильной разработки или тестировщиков. Чем дальше, тем зона неизвестного становится больше и больше ставка на самостоятельность человека, чем на следование прописанным обязанностям. Да, чем выше должность, тем ответственность выше, и хорошо бы снизить риски, но попытки формализовать функционал руководителя до такой же степени, как это возможно у линейного персонала — это чаще всего только попытки, которые не выходят за пределы бумаги.
                    0
                    Да совершенно не интересно функционал обсуждать.
                    Обязанности, ответственность, за что отвечает важно.
                    Входит в обязанности тимлида решение судьбы продукта? Нет
                    Входит в обязанности тимлида архитектура? Ну нет
                    Входит в обязанности тимлида финансы? Ну нет совершенно
              +1
              Спасибо за статью. Очень познавательно
                +10
                Мне очень нравится как ты выделил главные фразы, тому кто не любит читать большие тексты будет легко пробежаться по boldу. )
                  +1

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

                    +1
                    Спасибо за статью. У нас в компании считают что всем этим должен заниматься «ведущий программист» (senior). Теперь будет повод просить повышение :-D
                      0
                      senior — старший программист
                      ведущий программист — lead, principal
                        0
                        Переименовали должность — вот и повышение тебе
                          0
                          да, когда у нас только 3х разделения:
                          младший — студенты без знаний
                          программист — те что могут сами уже работать
                          и сразу ведущий программист — то что описано в статье.
                          выше это уже начальник отдела, направления и т.д.
                          Заметил такую же ситуацию практически во всех российский компаниях.
                          0
                          В каждой компании прораба называют по разному. Но меня тоже немного напрягают когда senior software engineer — это «ведущий программист», ведь по сути это «lead developer»…
                          0
                          Живенько написано, спасибо)
                            +3
                            Привет, Александр. Спасибо за статью.

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

                            А то я уже сталкивался с таким, подписан на несколько каналов, где тоже «опытные» делились своим опытом, а потом оказалось, что из 2 компаний их выгнали, а в некоторых они ничего так и не смогли построить и предложить.

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

                            Дак в каких ты говоришь компаниях работал на позиции руководителя, насколько они большие и известны ли их продукты на мировом рынке?

                            Это добавило бы вес твоим советам и словам, а то сам понимаешь любой может начать рассказывать как оно правильно и в этом потоке бреда и глупости единственным маркером уважения служит успешный опыт.
                              +1
                              Четкое замечание.
                              Еще в интернете гуляет совет — «чтобы в чем-то разобраться чего ты не знаешь, начни учить других людей», очень часто встречается подобное от «экспертов»
                              0
                              За 4 года уже неджуновой я работала в разных командах, в том числе и аутстафф. В основном тимлиды — это не должность как таковая, а роль, которую исполнял ведущий/старший разработчик определенного направления, в обязанности которого на проекте, помимо реализации собственных задач (высокий уровень, архитектура приложения/системы) включалось распределение задач по остальным членам команды и контроль за их исполнением, а также более плотное взаимодействие с руководителями проекта, аналитиками и другими командами. В нескольких проектах я сама выполняла роль тимлида.
                              Вообще заметила тенденцию, что сейчас очень часто путают тимлида с техлидом, который самим написанием кода, как правило, не занимается и берет на себя в основном управленческие функции
                                0

                                Это не путаница, а совмещение

                                0
                                Тебе придется быть хорошим


                                У меня в команде по сути два тимлида (т.к. > 20 чел сотрудников), и действует такое неформальное разделение на доброго и злого полицейского. Как правило, я выступаю в роли второго. Ну, то есть, я требовательна на грани, а мой коллега сглаживает острые углы и подбадривает. Что неплохо сказывается на результатах)
                                  0
                                  на самом деле тут имелось ввиду слово правильным, наверное. Не может человек дрочить других за косяки, которые и сам же совершает, это просто не работает. Но схема хороший-плохой работает, да
                                  0
                                  Добавлю ещё одну функцию тимлида — мониторинг зарплат на рынке труда и общение с вышестоящим руководством в случае, если текущие зарплаты сотрудников оказались ниже рынка, а это самое вышестоящее руководство не реагирует или не знает о ситуации. Для многих людей психологически проще пройти собеседование в другую фирму, чем идти просить повышение зарплаты на текущем месте работы.
                                    0
                                    С деньгами все очень сложно, во многих компаниях, в команде никто не знает кто сколько зарабатывает, этому есть объяснение, но зачастую тем, кто вышел из разработки, не особо доверяют финансы, это да.
                                    0
                                    Александр, добрый день.
                                    Я сравниваю вашу статью с «Как пасти котов» (по описанию проблем и путей выхода из них) и нахожу вашу статью более приближенной к реальности.
                                    Вопрос: как считаете, позиция тимлида отличается в продуктовой и не продуктовой компании?
                                      0
                                      не думаю, в деталях может отличаться, но в целом основной принцип остается тем же самым — управлять командой
                                      0
                                      В компании обычно выстраивается своя внутренняя культура. От компании к компании эта культура может очень сильно отличаться. А вместе с ней и обязанности отличаются.
                                      Но в данной статье автора смешал вообще все роли — менеджер проектов, бизнес-аналитик,
                                      системный аналитик, программист и тимлид. Руководитель проекта, владелец продукта и бизнес-аналитик обычно общаются с бизнесом. А тимлид нужен для организации своего коллектива в решении задач, а не для общения с бизнесом.
                                      В литературе часто понятия пересекаются, а на практике уж больно сильно обязанности зависят от культуры в компании, регламентов, применяемых методологий, процессов и компенсаций сотрудников.
                                        0
                                        далеко не всегда стоит использовать стиль соковыжималки

                                        Кажется уже столько статей написано (и ещё пара буквально на прошлой неделе) о том, что человек — не конвейер.
                                        Но тимлиды продолжают талдычить одно и то же.
                                        Кто вам вообще сказал, что стиль соковыжималки может дать хоть какой-то положительный результат?
                                          0
                                          Видел я реальное использование стиля соковыжималки. Итог был предсказуем — человек увольнялся.
                                            +1
                                            Обычно это и требуется, высушить человека, взять нового и гонять его до тех пор, пока не сдохнет. Знаю я пару компаний, использующий этот подход.
                                          0
                                          Многие моменты действительно очень интересно описаны — спасибо. Было бы здорово, если бы побольше кейсов, из вашей практики, добавили.
                                            0
                                            За статью спасибо, очень вовремя — через пару недель как раз выхожу тимлидом в уже сформированную команду, хоть и небольшую
                                              0
                                              Изучите должностные инструкции прораба. Какой там нафиг психологический климат в коллективе? Понапридумывают названия должностей и потом приспосабливаются к ним. Вид деятельности первичен, а он не отличается от сферы применения.
                                                0
                                                Ты должен стать тем самым интерфейсом, через который бизнес общается с командой разработки.


                                                Разве это не обязанность продукт-менеджера?

                                                Only users with full accounts can post comments. Log in, please.