Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Нет чёткого описания обязанностей стандартного тимлида, какие они?
А в описании присутствует очень много функций от ПМ и архитектора. Прямо комбайн, и финансы посчитай, и сопели протри и технологии выбери :)
А в описании присутствует очень много функций от ПМ и архитектора. Прямо комбайн, и финансы посчитай, и сопели протри и технологии выбери :)
Ага, ещё и код пиши.
Почитал, поудивлялся.
Описаны все функции ПМа на проекте :)
Оно и не странно… список профессий на этом сайте это сбор SEO текста, есть чудные отраслевые профессии Линк-менеджер и Специалист по информационным системам…
Если у человека в обязанностях стоит:
— заключение договора с клиентом;
— ведение договоров и других документов;
— оценку объёмов, бюджета и планирование сроков работ;
То он практически автоматом уже не может заниматься технической частью проекта как программист, как архитектор и т.д., ну не будет у него сил и времени даже на небольших проектах.
Описаны все функции ПМа на проекте :)
Оно и не странно… список профессий на этом сайте это сбор SEO текста, есть чудные отраслевые профессии Линк-менеджер и Специалист по информационным системам…
Если у человека в обязанностях стоит:
— заключение договора с клиентом;
— ведение договоров и других документов;
— оценку объёмов, бюджета и планирование сроков работ;
То он практически автоматом уже не может заниматься технической частью проекта как программист, как архитектор и т.д., ну не будет у него сил и времени даже на небольших проектах.
скорее да, сложно точно ограничить зону работы. Во многом зависит от возможностей компаний, разумности руководства. Да и в целом нигде нет талмута, который как 2+2 обозначил рабочие обязанности. Даже нет четких ограничений между senior и middle или middle и junior. Есть только размытые трактовки.
Да всё довольно чётко.
Тимлид (как программист) управляет группой разработчиков для достижения какой-то цели, разбирается в деталях разработки.
Джунион — ему всё надо рассказать как делать и проконтролировать.
Мидл — ему надо в общих чертах рассказать как делать и проконтролировать.
Сеньор — ему надо объяснить понятно что надо делать и всёравно проконтролировать.
Тимлид (как программист) управляет группой разработчиков для достижения какой-то цели, разбирается в деталях разработки.
Джунион — ему всё надо рассказать как делать и проконтролировать.
Мидл — ему надо в общих чертах рассказать как делать и проконтролировать.
Сеньор — ему надо объяснить понятно что надо делать и всёравно проконтролировать.
Ваше определение тимлида чем отличаются от техлида?
Ваши определения уровней разработчиков не кажутся ли размытой? Нет четкой грани разделения ). Они не отвечают на вопросы выбора уровней сложности назначаемых задач, скорости их реализации, выгодно ли это в итоге бизнесу(грубо говоря стоит ли набирать джунов, мидлов, может только сеньеров)
Ваши определения уровней разработчиков не кажутся ли размытой? Нет четкой грани разделения ). Они не отвечают на вопросы выбора уровней сложности назначаемых задач, скорости их реализации, выгодно ли это в итоге бизнесу(грубо говоря стоит ли набирать джунов, мидлов, может только сеньеров)
Техлид это же вообще не должность, а «звание» :)
Нет чёткой грани?
Она есть — если всё разжовано, то и джуниор сделает сложную задачу (если не сделает то нафиг вообще такого программиста).
Если недостаточно разжовано, то мидл может быть сделает задачу :)
Сениор же должен сделать полюбому, как ни крути или сказать что все дураки :)
Для бизнеса тоже всё чётко получается… главное чтобы кто-то от бизнеса умел «варить» программистов :)
Если у бизнеса есть тот кто будет жевать для джуниоров, если ему есть куда приткнуть джуниоров, чтобы они дешево выполняли финансово затратные задачи, то бери пожалуйста…
Если жевать за них некому, но есть кто-то кто может водить за собой мидлов, и по срокам мидлы укладываются, или если финансирование разработки не может сразу выложить сто тыщ мильёнов, то мидлы вполне для вас :)
Если у вас есть деньги и жгучее желание сделать быстро и хорошо, то сеньоры ваш единственный вариант.
Нет чёткой грани?
Она есть — если всё разжовано, то и джуниор сделает сложную задачу (если не сделает то нафиг вообще такого программиста).
Если недостаточно разжовано, то мидл может быть сделает задачу :)
Сениор же должен сделать полюбому, как ни крути или сказать что все дураки :)
Для бизнеса тоже всё чётко получается… главное чтобы кто-то от бизнеса умел «варить» программистов :)
Если у бизнеса есть тот кто будет жевать для джуниоров, если ему есть куда приткнуть джуниоров, чтобы они дешево выполняли финансово затратные задачи, то бери пожалуйста…
Если жевать за них некому, но есть кто-то кто может водить за собой мидлов, и по срокам мидлы укладываются, или если финансирование разработки не может сразу выложить сто тыщ мильёнов, то мидлы вполне для вас :)
Если у вас есть деньги и жгучее желание сделать быстро и хорошо, то сеньоры ваш единственный вариант.
мне приходилось заниматься этим всем, совместно и с проджектом, и с продуктом. Ну и очень часто тимлид, это еще подразумевает то, что ты будешь еще и техлидом. Но опять же, зависит от компании, подходов и размера команды
Так вот вы не написали, вы про тимлида-программиста или про тимлида-менеджера?
Первому я бы финансы даже не подумал делегировать, второму же лезть в технические детали не позволил.
Мне тоже приходилось заниматься всем, причём во все концы.
Первому я бы финансы даже не подумал делегировать, второму же лезть в технические детали не позволил.
Мне тоже приходилось заниматься всем, причём во все концы.
Тимлид разработчиков — мост между миром менеджеров и разработчиков. Его цель доносить мысль управленцев, заказчиков до команды в том виде, как они лучше понимают. Мышление у всех разное ). А также наоборот, объяснять заказчикам технические нюансы его требований на понятном ему языке.
Тимлид не мост, он организует работу группы программистов.
Менеджеру какая разница какому из N программистов говорить куда копать? Менеджер сказал куда копать — дальше программист «дурак» :)
Менеджеру накладно каждому из N программистов рассказывать куда им копать индивидуально!
Вот тимлид и появляется…
«объяснять заказчикам технические нюансы» — вся проблема дискуссий под статьёй из-за того, что понятия все в слова вкладывают разные.
Это вы про какого заказчика тут? Боже упаси тимлида в общем случае пускать рассказывать что-то внешнему заказчику!
Вы наверное про внутреннего заказчика? Про менеджера того самого :) Ну да, менеджеру стоит сразу сказать кто «дурак» если такой факт есть :)
Менеджеру какая разница какому из N программистов говорить куда копать? Менеджер сказал куда копать — дальше программист «дурак» :)
Менеджеру накладно каждому из N программистов рассказывать куда им копать индивидуально!
Вот тимлид и появляется…
«объяснять заказчикам технические нюансы» — вся проблема дискуссий под статьёй из-за того, что понятия все в слова вкладывают разные.
Это вы про какого заказчика тут? Боже упаси тимлида в общем случае пускать рассказывать что-то внешнему заказчику!
Вы наверное про внутреннего заказчика? Про менеджера того самого :) Ну да, менеджеру стоит сразу сказать кто «дурак» если такой факт есть :)
И дайте угадаю, за одну зарплатную ставку, да?
У меня в голове родилось аж три ответа, первый, самый простой — конечно, никто не будет платить тебе за троих, если ты работаешь за троих, хотя мне однажды предлагали поработать за еще одного программиста, но я решил, что 16 часовые рабочие смены — это не для меня.
Второй, у меня на тот момент все таки были и продукт, и прожект, которые так же занимались кучей разных вопросов, и более того, многие вещи мы делали совместно, кстати, я тогда у него многому научился, как например доносить не самую приятную информацию до людей, или как тактично договариваться с некоторыми людьми в команде. Кстати, я довольно часто сталкивался с тем, что со мной, как разработчиком общались менеджеры, без моего непосредственного руководителя, иногда это общение происходит на совершенно разных уровнях, что после него остается, довольно неприятный осадок, тимлид, как раз мог это соединить воедино. Иногда в таких общениях я узнавал много нового, иногда много нового узнавал менеджер.
Третий, меня никто не заставлял пахать за семерых и работать по 20 часов в сутки, от меня требовались определенные вещи, как я их буду добиваться — сидеть вместе с командой и писать код, или делать так, что бы за счет меня команда работала эффективнее — вопрос уже моей компетенции и моего руководства этими ребятами, тимлиды, которые не умеют за счет себя пустить команду — довольно хреново выполняют свою работу.
Но опять же, есть и те, кто просто таски из столбца в столбец перекидывают, на совещания ходят и смотрят, что бы каждый фаллосы не пинал в рабочее время.
Второй, у меня на тот момент все таки были и продукт, и прожект, которые так же занимались кучей разных вопросов, и более того, многие вещи мы делали совместно, кстати, я тогда у него многому научился, как например доносить не самую приятную информацию до людей, или как тактично договариваться с некоторыми людьми в команде. Кстати, я довольно часто сталкивался с тем, что со мной, как разработчиком общались менеджеры, без моего непосредственного руководителя, иногда это общение происходит на совершенно разных уровнях, что после него остается, довольно неприятный осадок, тимлид, как раз мог это соединить воедино. Иногда в таких общениях я узнавал много нового, иногда много нового узнавал менеджер.
Третий, меня никто не заставлял пахать за семерых и работать по 20 часов в сутки, от меня требовались определенные вещи, как я их буду добиваться — сидеть вместе с командой и писать код, или делать так, что бы за счет меня команда работала эффективнее — вопрос уже моей компетенции и моего руководства этими ребятами, тимлиды, которые не умеют за счет себя пустить команду — довольно хреново выполняют свою работу.
Но опять же, есть и те, кто просто таски из столбца в столбец перекидывают, на совещания ходят и смотрят, что бы каждый фаллосы не пинал в рабочее время.
Вот вы описали обычного тимлида — вместо того чтобы менеджерам гонять и получать фидбек от 3-10 программистов, они гоняют одного тимлида. Он для этого и нужен, он должен понимать зачем его «создали» :)
Если в компании уже есть потребность в тимлиде, то функции ПМ и архитектора вероятнее всего тоже найдется кому выполнять.
Не спрашивают с обычного тимлида за все провалы по проекту и за финансовое планирование.
Если в компании уже есть потребность в тимлиде, то функции ПМ и архитектора вероятнее всего тоже найдется кому выполнять.
Не спрашивают с обычного тимлида за все провалы по проекту и за финансовое планирование.
Это у линейных сотрудников есть чёткое описание обязанностей. Чем выше должность — тем больше в ваши обязанности входит всё то, что не входит в обязанности ваших подчинённых. Иногда что-то можно делегировать, а иногда просто нет человека со схожим функционалом и кто-то должен это делать. На топ-уровне оцениваются не обязанности, а результаты, сделанные продукты, урезанные расходы, полученная выручка и т.п., и не так важно, что именно вы делали для этого.
Чем выше должность — тем чётче описаны обязанности, т.к. «ответственность» выше.
Причём тут уровень топ менеджеров и тимлид? Вы про какую оргструктуру? Тимлид это должность под ПМ, CTO или руководителя отдела.
Вы пишите что тимлид ответственнен за продукт? И тимлид расходы по проекту можер урезать?
Причём тут уровень топ менеджеров и тимлид? Вы про какую оргструктуру? Тимлид это должность под ПМ, CTO или руководителя отдела.
Вы пишите что тимлид ответственнен за продукт? И тимлид расходы по проекту можер урезать?
Я нигде не употреблял слово тимлид и говорил о более общем принципе.
Касательно вашего первого тезиса, давайте тогда определим, что понимать под обязанностями. Я понимаю некоторый неизменный функционал, часто хорошо стандартизованный и описанный. По моему опыту чем выше должность, тем большую роль играют не обязанности, а цели на квартал, полугодие, другой период. Кроме того, большую часть работы составляет то, что предугадать и описать просто невозможно. Если для линейных сотрудников можно написать какие-то правила как действовать в непонятных ситуациях, то для их руководителя во-первых не очевидных ситуаций становится в 10 раз больше за счёт большего фронта работы и эскалации вопросов от подчинённых, а во-вторых отсутствует экспертиза по их решению. Как ген директор может хорошо прописать обязанности CTO, если его зона экспертизы это продажи (что чаще всего бывает), а не технологии. В лучшем случае будут средней степени проработки KPI, а в остальном от человека требуется проактивность и здравый смысл. С тимлидами ситуация конечно проще, так как часто его руководитель сам бывший тимлид, но он может быть тимлид бекенда, а нужно управлять тимлидом мобильной разработки или тестировщиков. Чем дальше, тем зона неизвестного становится больше и больше ставка на самостоятельность человека, чем на следование прописанным обязанностям. Да, чем выше должность, тем ответственность выше, и хорошо бы снизить риски, но попытки формализовать функционал руководителя до такой же степени, как это возможно у линейного персонала — это чаще всего только попытки, которые не выходят за пределы бумаги.
Касательно вашего первого тезиса, давайте тогда определим, что понимать под обязанностями. Я понимаю некоторый неизменный функционал, часто хорошо стандартизованный и описанный. По моему опыту чем выше должность, тем большую роль играют не обязанности, а цели на квартал, полугодие, другой период. Кроме того, большую часть работы составляет то, что предугадать и описать просто невозможно. Если для линейных сотрудников можно написать какие-то правила как действовать в непонятных ситуациях, то для их руководителя во-первых не очевидных ситуаций становится в 10 раз больше за счёт большего фронта работы и эскалации вопросов от подчинённых, а во-вторых отсутствует экспертиза по их решению. Как ген директор может хорошо прописать обязанности CTO, если его зона экспертизы это продажи (что чаще всего бывает), а не технологии. В лучшем случае будут средней степени проработки KPI, а в остальном от человека требуется проактивность и здравый смысл. С тимлидами ситуация конечно проще, так как часто его руководитель сам бывший тимлид, но он может быть тимлид бекенда, а нужно управлять тимлидом мобильной разработки или тестировщиков. Чем дальше, тем зона неизвестного становится больше и больше ставка на самостоятельность человека, чем на следование прописанным обязанностям. Да, чем выше должность, тем ответственность выше, и хорошо бы снизить риски, но попытки формализовать функционал руководителя до такой же степени, как это возможно у линейного персонала — это чаще всего только попытки, которые не выходят за пределы бумаги.
Спасибо за статью. Очень познавательно
Мне очень нравится как ты выделил главные фразы, тому кто не любит читать большие тексты будет легко пробежаться по boldу. )
Про делегирование я бы добавил, что помимо делегирования задач и ответственности стоит научиться делегировать полномочия. Про делегирование задач и коллективную ответственность все понятно, но стоит понимать что делегирование — это еще передача полномочий по принятию решений. Другими словами если ты делегировал задачу, будь готов, что ее могут исполнить не совсем так как ты ожидаешь.
Спасибо за статью. У нас в компании считают что всем этим должен заниматься «ведущий программист» (senior). Теперь будет повод просить повышение :-D
senior — старший программист
ведущий программист — lead, principal
ведущий программист — lead, principal
Переименовали должность — вот и повышение тебе
да, когда у нас только 3х разделения:
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
В каждой компании прораба называют по разному. Но меня тоже немного напрягают когда senior software engineer — это «ведущий программист», ведь по сути это «lead developer»…
Живенько написано, спасибо)
Привет, Александр. Спасибо за статью.
Скажи, пожалуйста, а мог бы ты рассказать в какой компании ты работал, работаешь и каких результатов тебе на позиции тимлида удалось достичь, какие проекты ты запустил со своей командой, с успехом которых можно было бы ознакомиться.
А то я уже сталкивался с таким, подписан на несколько каналов, где тоже «опытные» делились своим опытом, а потом оказалось, что из 2 компаний их выгнали, а в некоторых они ничего так и не смогли построить и предложить.
Ты делишься обширными знаниями и опытом и кажется, ты продвигаешь идею, что ты правильно руководишь и твои советы подкреплены осязаемыми достижениями и результатами.
Дак в каких ты говоришь компаниях работал на позиции руководителя, насколько они большие и известны ли их продукты на мировом рынке?
Это добавило бы вес твоим советам и словам, а то сам понимаешь любой может начать рассказывать как оно правильно и в этом потоке бреда и глупости единственным маркером уважения служит успешный опыт.
Скажи, пожалуйста, а мог бы ты рассказать в какой компании ты работал, работаешь и каких результатов тебе на позиции тимлида удалось достичь, какие проекты ты запустил со своей командой, с успехом которых можно было бы ознакомиться.
А то я уже сталкивался с таким, подписан на несколько каналов, где тоже «опытные» делились своим опытом, а потом оказалось, что из 2 компаний их выгнали, а в некоторых они ничего так и не смогли построить и предложить.
Ты делишься обширными знаниями и опытом и кажется, ты продвигаешь идею, что ты правильно руководишь и твои советы подкреплены осязаемыми достижениями и результатами.
Дак в каких ты говоришь компаниях работал на позиции руководителя, насколько они большие и известны ли их продукты на мировом рынке?
Это добавило бы вес твоим советам и словам, а то сам понимаешь любой может начать рассказывать как оно правильно и в этом потоке бреда и глупости единственным маркером уважения служит успешный опыт.
За 4 года уже неджуновой я работала в разных командах, в том числе и аутстафф. В основном тимлиды — это не должность как таковая, а роль, которую исполнял ведущий/старший разработчик определенного направления, в обязанности которого на проекте, помимо реализации собственных задач (высокий уровень, архитектура приложения/системы) включалось распределение задач по остальным членам команды и контроль за их исполнением, а также более плотное взаимодействие с руководителями проекта, аналитиками и другими командами. В нескольких проектах я сама выполняла роль тимлида.
Вообще заметила тенденцию, что сейчас очень часто путают тимлида с техлидом, который самим написанием кода, как правило, не занимается и берет на себя в основном управленческие функции
Вообще заметила тенденцию, что сейчас очень часто путают тимлида с техлидом, который самим написанием кода, как правило, не занимается и берет на себя в основном управленческие функции
Тебе придется быть хорошим
У меня в команде по сути два тимлида (т.к. > 20 чел сотрудников), и действует такое неформальное разделение на доброго и злого полицейского. Как правило, я выступаю в роли второго. Ну, то есть, я требовательна на грани, а мой коллега сглаживает острые углы и подбадривает. Что неплохо сказывается на результатах)
Добавлю ещё одну функцию тимлида — мониторинг зарплат на рынке труда и общение с вышестоящим руководством в случае, если текущие зарплаты сотрудников оказались ниже рынка, а это самое вышестоящее руководство не реагирует или не знает о ситуации. Для многих людей психологически проще пройти собеседование в другую фирму, чем идти просить повышение зарплаты на текущем месте работы.
Александр, добрый день.
Я сравниваю вашу статью с «Как пасти котов» (по описанию проблем и путей выхода из них) и нахожу вашу статью более приближенной к реальности.
Вопрос: как считаете, позиция тимлида отличается в продуктовой и не продуктовой компании?
Я сравниваю вашу статью с «Как пасти котов» (по описанию проблем и путей выхода из них) и нахожу вашу статью более приближенной к реальности.
Вопрос: как считаете, позиция тимлида отличается в продуктовой и не продуктовой компании?
В компании обычно выстраивается своя внутренняя культура. От компании к компании эта культура может очень сильно отличаться. А вместе с ней и обязанности отличаются.
Но в данной статье автора смешал вообще все роли — менеджер проектов, бизнес-аналитик,
системный аналитик, программист и тимлид. Руководитель проекта, владелец продукта и бизнес-аналитик обычно общаются с бизнесом. А тимлид нужен для организации своего коллектива в решении задач, а не для общения с бизнесом.
В литературе часто понятия пересекаются, а на практике уж больно сильно обязанности зависят от культуры в компании, регламентов, применяемых методологий, процессов и компенсаций сотрудников.
Но в данной статье автора смешал вообще все роли — менеджер проектов, бизнес-аналитик,
системный аналитик, программист и тимлид. Руководитель проекта, владелец продукта и бизнес-аналитик обычно общаются с бизнесом. А тимлид нужен для организации своего коллектива в решении задач, а не для общения с бизнесом.
В литературе часто понятия пересекаются, а на практике уж больно сильно обязанности зависят от культуры в компании, регламентов, применяемых методологий, процессов и компенсаций сотрудников.
далеко не всегда стоит использовать стиль соковыжималки
Кажется уже столько статей написано (и ещё пара буквально на прошлой неделе) о том, что человек — не конвейер.
Но тимлиды продолжают талдычить одно и то же.
Кто вам вообще сказал, что стиль соковыжималки может дать хоть какой-то положительный результат?
Многие моменты действительно очень интересно описаны — спасибо. Было бы здорово, если бы побольше кейсов, из вашей практики, добавили.
За статью спасибо, очень вовремя — через пару недель как раз выхожу тимлидом в уже сформированную команду, хоть и небольшую
Изучите должностные инструкции прораба. Какой там нафиг психологический климат в коллективе? Понапридумывают названия должностей и потом приспосабливаются к ним. Вид деятельности первичен, а он не отличается от сферы применения.
Ты должен стать тем самым интерфейсом, через который бизнес общается с командой разработки.
Разве это не обязанность продукт-менеджера?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое быть тимлидом