Комментарии 46
А есть ли обратная проверка записок тимлида? Если в т.ч. на основании записок происходит пересмотр ЗП, то как проверить Вас?
Пересмотр ЗП не происходит на основании только лишь записей лида. Это помогает лиду дать обратную связь по работе сотрудника. Не я одна принимаю решение, поэтому, если я несправедлива — мне обязательно об этом скажут
Я не имел в виду, что Вы не справедлива. Не берусь оценивать, я Вас не знаю. Просто хотел уточнить, что не Вы одна принимаете такие решения. Благодарю за ответ.
Может быть мой вопрос может показаться глупым, но мне действительно интересно как Вы работаете над объективностью содержания записок. Вот если убрать административное содержание записок (опоздания, конфликты и т.п.), оставить только технические заметки, как Вы принимаете решение, что именно записать. Вы прекрасно знаете, что ситуации бывают не однозначные, и порой непонятно кто действительно молодец а кто негодяй из-за которого произошёл отказ. Отказы есть у всех, это нормально. Абдула Абдулаев мог хотфиксить в пятницу, потому что сам допустил ошибку, а мог это сделать из-за Мухамеда Мухамедова и его костыля на стейдже, работающим не как на проде. Я утрирую, конечно, это пример. Вот совершенно не понятная ситуация, локдаун на час, что Вы запишите у себя? А через полгода об этом никто помнить не будет, в т.ч. сотрудник, тем более детали произошедшего. А будет только заметка от Вас… Понимаете, о чём я? Перефразирую вопрос, как исключить человеческий фактор из оценки сотрудника посредством личных заметок?
Может быть мой вопрос может показаться глупым, но мне действительно интересно как Вы работаете над объективностью содержания записок. Вот если убрать административное содержание записок (опоздания, конфликты и т.п.), оставить только технические заметки, как Вы принимаете решение, что именно записать. Вы прекрасно знаете, что ситуации бывают не однозначные, и порой непонятно кто действительно молодец а кто негодяй из-за которого произошёл отказ. Отказы есть у всех, это нормально. Абдула Абдулаев мог хотфиксить в пятницу, потому что сам допустил ошибку, а мог это сделать из-за Мухамеда Мухамедова и его костыля на стейдже, работающим не как на проде. Я утрирую, конечно, это пример. Вот совершенно не понятная ситуация, локдаун на час, что Вы запишите у себя? А через полгода об этом никто помнить не будет, в т.ч. сотрудник, тем более детали произошедшего. А будет только заметка от Вас… Понимаете, о чём я? Перефразирую вопрос, как исключить человеческий фактор из оценки сотрудника посредством личных заметок?
Весьма интересная статья. Судя по описанию в этой должности гораздо больше гуманитарной составляющей, тем технической?
Тимлиду желательно разбираться в тонкостях человеческих взаимотношений не хуже, чем в коде.
А надо ли разбираться в коде?
К вопросу про код. В статье про код ничего нет, а есть интересный и полезный документ.
Его содержание вполне соответствует работе в рамках Менеджер по персоналу
- Выявление потребности в обучении персонала;
- Организация обучения персонала, координация работы по повышению квалификации сотрудников и развитию их карьеры;
- Проведение адаптационных мероприятий;
- Разработка и реализация программ обучения и развития;
- Формирование и управление корпоративной культурой Компании;
- Развитие лояльности и вовлеченности сотрудников;
- Организация мероприятий, направленных на повышение сплоченности коллектива;
- Проведение семинаров и тренингов;
- Контроль состояния трудовой дисциплины, инициирование и организация мероприятий по ее поддержанию
И это только часть обязанностей :)
В этой статье я не описываю все аспекты должности тимлида. Здесь лишь приведен инструмент, который поможет фиксировать нужное, чтобы иметь быстрый доступ к информации. И я нигде не указала, что моя работа состоит только из этих активностей. В начале статьи отмечено, что речь пойдет об отдельной сфере — работе с людьми. И это лишь часть того, что делает тимлид. Технический бэкграунд нужен, и он у меня есть
Это задачи HR, PM, но точно не тимлида (ну кроме собеседований).
Задачи тимлида — организация кода, рабочего процесса и взаимодействий с другими командами.
Пример хорошей организации — когда Петр Перов не хотфиксит ночью в пятницу, а Егоров Егор занимается разработкой на JAVA как ведущий инженер, а не пишет автотесты на SCALA, как middle QA специалист.
Если у вас при такой организации все хорошо работает технически, то оглядитесь — скорее всего у вас уже есть настоящий тимлид, просто вы его еще не назначили.
Задачи тимлида — организация кода, рабочего процесса и взаимодействий с другими командами.
Пример хорошей организации — когда Петр Перов не хотфиксит ночью в пятницу, а Егоров Егор занимается разработкой на JAVA как ведущий инженер, а не пишет автотесты на SCALA, как middle QA специалист.
Если у вас при такой организации все хорошо работает технически, то оглядитесь — скорее всего у вас уже есть настоящий тимлид, просто вы его еще не назначили.
Если у вас при такой организации все хорошо работает технически, то оглядитесь — скорее всего у вас уже есть настоящий тимлид, просто вы его еще не назначили.
А как называется должность того, кто оглядывается и занимается подбными назначениями?
Руководитель разработки.
> А как называется должность того, кто оглядывается и занимается подбными назначениями?
Product owner или CTO. Но явно не тот, кто считает что поставить QAшника тимлидом разработчиков — отличная идея. Тимлидом должен быть разработчик, иначе получится то что описано в статье — психологические игры, а не выстраивание разработки.
Product owner или CTO. Но явно не тот, кто считает что поставить QAшника тимлидом разработчиков — отличная идея. Тимлидом должен быть разработчик, иначе получится то что описано в статье — психологические игры, а не выстраивание разработки.
У нас есть разные подходы к орг. структуре.
По-большей части да, тимлиды имеют бэкграунд разработки.
Но мы также практикует структуру — тимлид не разработчик + техлид(ы).
Все зависит от задач и размера команды.
По-большей части да, тимлиды имеют бэкграунд разработки.
Но мы также практикует структуру — тимлид не разработчик + техлид(ы).
Все зависит от задач и размера команды.
То есть для вас тимлид — это не эксперт, который обладает достаточными компетенциями в процессах разработки и проекте, которыми он занимается, и который принимает технические и архитектурные решения, и обладает достаточным авторитетом в команде, а менеджер по персоналу, которого поставили сверху приглядывать за программистами?
Решение ваше, а от себя могу лишь порадовваться, что отсылал ваших рекрутеров, тем кто хочет строить карьеру в IT, в вашей компании делать нечего, ведь каким бы хорошим программистом бы ты не был, ты все равно будешь кандидатом на тимлида хуже, чем блондинка — куашница.
Решение ваше, а от себя могу лишь порадовваться, что отсылал ваших рекрутеров, тем кто хочет строить карьеру в IT, в вашей компании делать нечего, ведь каким бы хорошим программистом бы ты не был, ты все равно будешь кандидатом на тимлида хуже, чем блондинка — куашница.
ведь каким бы хорошим программистом бы ты не был, ты все равно будешь кандидатом на тимлида хуже
А почему хочется попасть именно на "тимлида" а не на "техлида"? Перечисленное в статье — это же работа с людьми, подходят ли тут навыки "хорошего программиста"?
К тому же, может быть влияние Shoom3301 на ФОТ и сетку тарифов таково, что техлид больше получает :)
Или в резюме хочется получить именно строку "тимлид"?
Перечисленное в статье — это задачи HR и PM, а не тимлида. Вы как угодно можете называть должности в тинькове, но когда в резюме пишется строчка «teamlead команды разработки», там подразумевается конкретный спектр обязанностей технического плана, «играющего тренера», а не менеджер по персоналу + немного PM.
А много ли куашница может рассказать программисту, многому ли сможет обучить или подсказать по коду? Или просто все обязанности тимлида свалятся на техлида (как это и происходит судя по всему в тинькове)?
Хорошо получается — сверху поставили кого-то, кто в разработке не шарит и строчит записочки целыми днями, а на техлида всех собак технических по продукту спустили, еще и джунов с процессами повесили. Тут не то что о карьерном росте заикаться тут как бы не выгореть в хлам и не запроситься обратно в программисты.
Даже в статье уже есть намеки на некомпетентность данного специалиста в вопросе повышения зп. Вот, например, Петр Петров хотфиксил в пятницу вечером. Куашнице это говорит что он хороший и готов помочь проекту. Программисту же это говорит что он раздолбай, потому что выложил не до конца проверенную функциональность перед выходными. для куашницы то, что ведущий инженер занимается автотестами — это хорошо, а для программиста — сигнал того, что человек вместо выполнения своих прямых обязанностей занимается прокастинацией в виде «изучения» скалы и автотестов, вместо работы над своими прямыми обязанностями.
И так далее. А потом людей повышают только за то что они громче всех вякали на совещаниях, и вместо качественного продукта мы получаем неподдерживаемое нечто, чьи карточки не видят в упор зарубежные терминалы или чьи платежи висят в авторизации по несколько дней.
А много ли куашница может рассказать программисту, многому ли сможет обучить или подсказать по коду? Или просто все обязанности тимлида свалятся на техлида (как это и происходит судя по всему в тинькове)?
Хорошо получается — сверху поставили кого-то, кто в разработке не шарит и строчит записочки целыми днями, а на техлида всех собак технических по продукту спустили, еще и джунов с процессами повесили. Тут не то что о карьерном росте заикаться тут как бы не выгореть в хлам и не запроситься обратно в программисты.
Даже в статье уже есть намеки на некомпетентность данного специалиста в вопросе повышения зп. Вот, например, Петр Петров хотфиксил в пятницу вечером. Куашнице это говорит что он хороший и готов помочь проекту. Программисту же это говорит что он раздолбай, потому что выложил не до конца проверенную функциональность перед выходными. для куашницы то, что ведущий инженер занимается автотестами — это хорошо, а для программиста — сигнал того, что человек вместо выполнения своих прямых обязанностей занимается прокастинацией в виде «изучения» скалы и автотестов, вместо работы над своими прямыми обязанностями.
И так далее. А потом людей повышают только за то что они громче всех вякали на совещаниях, и вместо качественного продукта мы получаем неподдерживаемое нечто, чьи карточки не видят в упор зарубежные терминалы или чьи платежи висят в авторизации по несколько дней.
Жаль, что в вашем понятии «команда разработки» — это только разработчики. Я нигде не упомянула, что руковожу разработчиками, и не знаю, почему вы вдруг начали такие споры о том, должна ли я писать код или нет. В команду разработки продукта могут входить не только разработчики, в ней есть и другие роли.
По поводу хотфикса — скорее, тут речь была о лояльности к своему продукту. Далеко не всегда это происходит так, как вы пишете. Возможно, команде действительно нужно было что-то исправить, и вся команда осталась (а не конкретный вымышленный человек, которого вы обвинили во всех смертных грехах :) )
По автоматизации — разве специалисты не могут действительно учиться чему-то новому? Они что, в этот момент «делают вид»?
Ну, и про качественный продукт — сама пользовалась нашей картой в других странах, всё прекрасно работает
По поводу хотфикса — скорее, тут речь была о лояльности к своему продукту. Далеко не всегда это происходит так, как вы пишете. Возможно, команде действительно нужно было что-то исправить, и вся команда осталась (а не конкретный вымышленный человек, которого вы обвинили во всех смертных грехах :) )
По автоматизации — разве специалисты не могут действительно учиться чему-то новому? Они что, в этот момент «делают вид»?
Ну, и про качественный продукт — сама пользовалась нашей картой в других странах, всё прекрасно работает
То есть в статье про разработчиков (хотфиксы итд), и команду разработки, но вы руководите не разработчиками. Очень интересно бы послушать, кто они тогда?
А записочка пошла плюсиком одному человеку? Где же обьективность тогда этой записочки?
Конечно могут. В нерабочее время. В рабочее время они должны совершенствовать свои рабочие навыки. Или вы считаете что middle QA это тоже самое что и Senior dev? Или разница в зп и в обязанностях нивелируется, когда сотрудник хочет узнать что-то новое за счет работодателя?
Ну и про качество продукта — очень весело бегать по Алании в поисках банкомата не Акбанка, потому что Акбанк отказывался выдавать мне лиры с тиньковской карты. А гиды в отелях просят платить сбером, потому что тиньков не работает на терминалах некоторых банков, они даже в курсе каких именно. Да что там Акбанк, сбер иногда отказывается ваши карты принимать в банкомат. Причем иногда принимает, иногда — нет. И началось такое последние пару лет, видимо когда разрабы стали куашить, а куашники — что-то делать в команде разработки с не разработчиками.
вся команда осталась
А записочка пошла плюсиком одному человеку? Где же обьективность тогда этой записочки?
разве специалисты не могут действительно учиться чему-то новому?
Конечно могут. В нерабочее время. В рабочее время они должны совершенствовать свои рабочие навыки. Или вы считаете что middle QA это тоже самое что и Senior dev? Или разница в зп и в обязанностях нивелируется, когда сотрудник хочет узнать что-то новое за счет работодателя?
Ну и про качество продукта — очень весело бегать по Алании в поисках банкомата не Акбанка, потому что Акбанк отказывался выдавать мне лиры с тиньковской карты. А гиды в отелях просят платить сбером, потому что тиньков не работает на терминалах некоторых банков, они даже в курсе каких именно. Да что там Акбанк, сбер иногда отказывается ваши карты принимать в банкомат. Причем иногда принимает, иногда — нет. И началось такое последние пару лет, видимо когда разрабы стали куашить, а куашники — что-то делать в команде разработки с не разработчиками.
Команда разработки — НЕ только разработчики. Есть и другие роли.
По поводу «хотфикса», за который вы так зацепились — еще раз повторю, это пример, и его не стоит воспринимать так буквально и додумывать что-то. Вы сами додумали, что это за ситуация и кому пошла «записочка».
На остальное не вижу смысла отвечать, так как тут придуманные вами факты и я не буду разбираться в плодах вашей фантазии
По поводу «хотфикса», за который вы так зацепились — еще раз повторю, это пример, и его не стоит воспринимать так буквально и додумывать что-то. Вы сами додумали, что это за ситуация и кому пошла «записочка».
На остальное не вижу смысла отвечать, так как тут придуманные вами факты и я не буду разбираться в плодах вашей фантазии
Боюсь нет смысла с вами дискутировать, если вы мыслите стереотипами и судите людей которых не знаете, это низко.
Для HR И PM это основные задачи, а для тимлида это инструменты работы с людьми. Организация рабочего процесса и взаимодействия с другими командами — это работа с людьми. Понимать своих сотрудников и знать их сильные и слабые стороны не менее важно, чем разбираться в коде. Понимать коллег из других отделов тоже важно, чтобы коммуникация давала позитивные результаты.
Предположим Егор Егоров энтузиаст и любит решать новые нетривиальные задачи, а Пётр Петров предпочитает монотонную работу и любые новшества для него стресс. Предположим тимлид решил что для него самое важное это код, а в людях ему разбираться незачем, поэтому он делает как сам считает нужным и даёт Петрову задания по внедрению новых технологий, а Егорову монотонные задачки по исправлению ошибок.
В результате Егорову скучно, Петров постоянно пребывает в стрессовом состоянии. Оба стесняются спорить с лидом, т.к. он личность авторитетная — много лет в разработке, во всём разбирается, значит ему виднее.
По факту получается, что эффективность труда ниже, чем если бы каждый сотрудник получил соответствующее его интересам задание. Со временим эффективность падает, т.к. сотрудники каждый день делают работу, которая им не нравится, плюс ко всему вероятность развития сотрудника в таких условиях низка. В итоге это всё может привести к проблемам со сроками или качеством и даже к увольнению сотрудника по собственному желанию.
Всего этого тимлид может избежать, проанализировав своего сотрудника, как по его поведению, результатам работы, так и просто встретившись и пообщавшись с ним на тему того, что ему интересно, что его не устраивает. Здесь же он может поделиться с сотрудником своими впечатлениями от его работы (естественно, диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»).
Также стоит отметить, что HR и PM первым будут спрашивать о сотруднике как раз у тимлида — как справляется Егоров, насколько эффективен Петров, просто потому что HR и RM не работают с этим сотрудником каждый день, а также не могут оценить его с профессиональной точки зрения так как не разбираются в его сфере. В этом случае тимлиду также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит. Просто каждый смотрел со своей колокольни, а в итоге вместо ожидаемого повышения сотрудник получит нагоняй и кукиш с маслом, что естественно скажется на его отношении к руководству и тимлиду, да и желание работать поутихнет.
Да, в статье собраны самые простые и распространённые менеджерские инструменты, но ничто не мешает тимлиду ими пользоваться в своей работе. Поверьте, если помимо крутана-кодера, Вы будете для своих сотрудников ещё и хорошим руководителем, понимающим их потребности и справедливо оценивающим их работу, хуже не будет точно.
Предположим Егор Егоров энтузиаст и любит решать новые нетривиальные задачи, а Пётр Петров предпочитает монотонную работу и любые новшества для него стресс. Предположим тимлид решил что для него самое важное это код, а в людях ему разбираться незачем, поэтому он делает как сам считает нужным и даёт Петрову задания по внедрению новых технологий, а Егорову монотонные задачки по исправлению ошибок.
В результате Егорову скучно, Петров постоянно пребывает в стрессовом состоянии. Оба стесняются спорить с лидом, т.к. он личность авторитетная — много лет в разработке, во всём разбирается, значит ему виднее.
По факту получается, что эффективность труда ниже, чем если бы каждый сотрудник получил соответствующее его интересам задание. Со временим эффективность падает, т.к. сотрудники каждый день делают работу, которая им не нравится, плюс ко всему вероятность развития сотрудника в таких условиях низка. В итоге это всё может привести к проблемам со сроками или качеством и даже к увольнению сотрудника по собственному желанию.
Всего этого тимлид может избежать, проанализировав своего сотрудника, как по его поведению, результатам работы, так и просто встретившись и пообщавшись с ним на тему того, что ему интересно, что его не устраивает. Здесь же он может поделиться с сотрудником своими впечатлениями от его работы (естественно, диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»).
Также стоит отметить, что HR и PM первым будут спрашивать о сотруднике как раз у тимлида — как справляется Егоров, насколько эффективен Петров, просто потому что HR и RM не работают с этим сотрудником каждый день, а также не могут оценить его с профессиональной точки зрения так как не разбираются в его сфере. В этом случае тимлиду также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит. Просто каждый смотрел со своей колокольни, а в итоге вместо ожидаемого повышения сотрудник получит нагоняй и кукиш с маслом, что естественно скажется на его отношении к руководству и тимлиду, да и желание работать поутихнет.
Да, в статье собраны самые простые и распространённые менеджерские инструменты, но ничто не мешает тимлиду ими пользоваться в своей работе. Поверьте, если помимо крутана-кодера, Вы будете для своих сотрудников ещё и хорошим руководителем, понимающим их потребности и справедливо оценивающим их работу, хуже не будет точно.
Спасибо, хорошее разъяснение. Основная задача тимлида — сделать так, чтобы команда работала эффективно и ее члены были счастливы. Для решения этих задач более важны навыки работы с людьми и понимание процессов разработки.
Занятно, что некоторые комментаторы напрочь забыли про суть статьи и бросились обсуждать совершенно другую тему :)
Занятно, что некоторые комментаторы напрочь забыли про суть статьи и бросились обсуждать совершенно другую тему :)
> Предположим Егор Егоров энтузиаст и любит решать новые нетривиальные задачи, а Пётр Петров предпочитает монотонную работу и любые новшества для него стресс.
Очень интересно от вас услышать, как человек, не имеющий отношения к коду, поймет какая задача тривиальна, а какая монотонна?
> Оба стесняются спорить с лидом
Для этого есть ретроспектива, на которой всегда можно обьяснить свою позицию, а не бегать по кабинетикам и собирать слюни, как то предлагает автор статьи
> диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»
Ну конечно, куашница то поймет в чем именно проблема и почему эта часть системы, которая вызвала у человека стресс, так построена.
> также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит.
Верно. А что является объективной оценкой? Perfomance review, который может провести только программист, понимающий разработческий объем, а не девочка, которая просто была на митингах и делала записочки о работе, и для которой куда больше плюсов от того что человек в пятницу вечером фиксил прод, чем от того что человек закрывал все свои задачи по спринту и брал с беклога стабильно еще на 10 сторипоинтов сверху.
Поэтому и есть должности PM, и есть должность тимлида, и поэтому тимлид должен быть разработчиком в любой орг структуре, просто чтобы понимать то, как программисты работают и что именно они делают, только так можно обьяснить члену команды где он не прав, и объективно понять что он делает хорошо, а что делает не так, и на своем ли он месте.
Если вы думаете что я ни разу не был в командах, где пытались в руководство просунуть своего человека, который не шарит, вы ошибаетесь, и всегда это приводило к плачевным результатам. А если считаете иначе — есть сайт «любимое.ит», там через раз такие истории, и в красках описано к чему такое приводит.
Очень интересно от вас услышать, как человек, не имеющий отношения к коду, поймет какая задача тривиальна, а какая монотонна?
> Оба стесняются спорить с лидом
Для этого есть ретроспектива, на которой всегда можно обьяснить свою позицию, а не бегать по кабинетикам и собирать слюни, как то предлагает автор статьи
> диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»
Ну конечно, куашница то поймет в чем именно проблема и почему эта часть системы, которая вызвала у человека стресс, так построена.
> также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит.
Верно. А что является объективной оценкой? Perfomance review, который может провести только программист, понимающий разработческий объем, а не девочка, которая просто была на митингах и делала записочки о работе, и для которой куда больше плюсов от того что человек в пятницу вечером фиксил прод, чем от того что человек закрывал все свои задачи по спринту и брал с беклога стабильно еще на 10 сторипоинтов сверху.
Поэтому и есть должности PM, и есть должность тимлида, и поэтому тимлид должен быть разработчиком в любой орг структуре, просто чтобы понимать то, как программисты работают и что именно они делают, только так можно обьяснить члену команды где он не прав, и объективно понять что он делает хорошо, а что делает не так, и на своем ли он месте.
Если вы думаете что я ни разу не был в командах, где пытались в руководство просунуть своего человека, который не шарит, вы ошибаетесь, и всегда это приводило к плачевным результатам. А если считаете иначе — есть сайт «любимое.ит», там через раз такие истории, и в красках описано к чему такое приводит.
У Вас какое-то предвзятое отношение к автору. Согласен что QA инженер не слишком подходит на роль лида разработчиков, но мы с Вами не знаем ничего об авторе — может она долгие годы занималась разработкой, потом QA, а потом снова разработкой. Мы также не знаем ничего о структуре команды, в которой работает автор — возможно там 40 разработчиков, в таких условиях любой человек, будь он кодер от бога, порвётся на части, поэтому, возможно, там ещё есть несколько саб-лидов, которые как раз решают технические вопросы и в такой структуре вполне может существовать тимлид с другой специальностью.
В любом случае, всё это не имеет отношения к статье. Кира собрала материал, который одинаково будет полезен любому тимлиду в любой сфере. Если Вас стриггерили две букы QA и после этого глаза застлала пелена отрицания, то откройте гугл и поищите про 1:1, SMART и другие вещи, которые упоминает автор. Извлеките пользу для себя, вместо того чтобы изливать негатив на человека, о котором Вы ничего не знаете.
Достаточно просто спросить у самого сотрудника. Давайте сравним две ситуации.
Ситуация первая. Лид — разработчик с 20-летнем стажем. Он дал джуну задание, которое на его взгляд очень простое (он все 20 лет такие задачи выполнял), но для джуна, которому он её дал, эта задача неподъёмна (он умный и старательный, но у него просто не достаточно опыта и это нормально — он ведь джун). Джун понимает, что задание сложное, но не возражает, т.к. во-первых ему интересно развиваться, во-вторых он полагается на авторитет лида. Джун промусолил задачу две недели, так и не справившись, лид был вынужден забрать задачу и допиливать сам в вечер пятницы. В итоге задача не выполнена, лид считает джуна дурачком, потому что тот не справился с простой (на взгляд лида) задачей, джун расстроен.
Ситуация вторая. Лид — «куашница». Дала тому же самому джуну то же самое задание. При этом она спросила у джуна справится ли он, тот ответил что он такого раньше не делал, но с радостью возьмётся т.к. хочет развиваться. Предположим нагрузка на проекте сейчас небольшая и сроки не поджимают (в противном случае можно сразу перенаправить задачу на более опытного сотрудника). Тогда есть смысл поддержать энтузиазм джуна и дать ему задачу, но назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс, чтобы задача всё-таки была выполненна в срок (если через неделю прогресса не будет, то можно передать задачу другому сотруднику, чтобы не допиливать в вечер пятницы). В итоге получаем — задача выполнена в срок, джун получил полезный опыт, мидл/сеньор получил опыт менторства. Все довольны.
Как видите, знание кода не спасает от всех проблем.
Ретроспектива проводится полной командой и на ней обсуждаются рабочие вопросы, это не время для личных разговоров. К тому же в разговоре 1:1 человеку куда проще озвучивать своё мнение. На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Чтобы понять что у человека стресс, не нужно разбираться как построена система.
Если ребёнок плачет из-за сломанной игрушки, Вам не нужно знать из каких деталей и как собрана игрушка, чтобы понять что он расстроен.
Мне кажется у Вас наболело. Ни в статье, ни в комментах про пропихивание своих людей не упоминалось. Конечно это есть и конечно результаты плачевные, но какое отношение это имеет к теме статьи? Если у вас негативный опыт с QA тимлидами, пропихнутыми на позицию их родственниками, это совсем не значит, что все QA лиды негодяи и оказались на своём месте незаслуженно.
И с чего Вы взяли что я про Вас что-то думаю? Я лишь постарался обратить внимание, что в статье приведены методы, которые будут полезны любому лиду. И имеет смысл хотя бы подумать как Вам это может помочь в работе, а не агриться на автора из-за его специализации.
В любом случае, всё это не имеет отношения к статье. Кира собрала материал, который одинаково будет полезен любому тимлиду в любой сфере. Если Вас стриггерили две букы QA и после этого глаза застлала пелена отрицания, то откройте гугл и поищите про 1:1, SMART и другие вещи, которые упоминает автор. Извлеките пользу для себя, вместо того чтобы изливать негатив на человека, о котором Вы ничего не знаете.
Очень интересно от вас услышать, как человек, не имеющий отношения к коду, поймет какая задача тривиальна, а какая монотонна?
Достаточно просто спросить у самого сотрудника. Давайте сравним две ситуации.
Ситуация первая. Лид — разработчик с 20-летнем стажем. Он дал джуну задание, которое на его взгляд очень простое (он все 20 лет такие задачи выполнял), но для джуна, которому он её дал, эта задача неподъёмна (он умный и старательный, но у него просто не достаточно опыта и это нормально — он ведь джун). Джун понимает, что задание сложное, но не возражает, т.к. во-первых ему интересно развиваться, во-вторых он полагается на авторитет лида. Джун промусолил задачу две недели, так и не справившись, лид был вынужден забрать задачу и допиливать сам в вечер пятницы. В итоге задача не выполнена, лид считает джуна дурачком, потому что тот не справился с простой (на взгляд лида) задачей, джун расстроен.
Ситуация вторая. Лид — «куашница». Дала тому же самому джуну то же самое задание. При этом она спросила у джуна справится ли он, тот ответил что он такого раньше не делал, но с радостью возьмётся т.к. хочет развиваться. Предположим нагрузка на проекте сейчас небольшая и сроки не поджимают (в противном случае можно сразу перенаправить задачу на более опытного сотрудника). Тогда есть смысл поддержать энтузиазм джуна и дать ему задачу, но назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс, чтобы задача всё-таки была выполненна в срок (если через неделю прогресса не будет, то можно передать задачу другому сотруднику, чтобы не допиливать в вечер пятницы). В итоге получаем — задача выполнена в срок, джун получил полезный опыт, мидл/сеньор получил опыт менторства. Все довольны.
Как видите, знание кода не спасает от всех проблем.
Для этого есть ретроспектива, на которой всегда можно обьяснить свою позицию
Ретроспектива проводится полной командой и на ней обсуждаются рабочие вопросы, это не время для личных разговоров. К тому же в разговоре 1:1 человеку куда проще озвучивать своё мнение. На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Ну конечно, куашница то поймет в чем именно проблема и почему эта часть системы, которая вызвала у человека стресс, так построена.
Чтобы понять что у человека стресс, не нужно разбираться как построена система.
Если ребёнок плачет из-за сломанной игрушки, Вам не нужно знать из каких деталей и как собрана игрушка, чтобы понять что он расстроен.
Если вы думаете что я ни разу не был в командах, где пытались в руководство просунуть своего человека, который не шарит, вы ошибаетесь, и всегда это приводило к плачевным результатам. А если считаете иначе — есть сайт «любимое.ит», там через раз такие истории, и в красках описано к чему такое приводит.
Мне кажется у Вас наболело. Ни в статье, ни в комментах про пропихивание своих людей не упоминалось. Конечно это есть и конечно результаты плачевные, но какое отношение это имеет к теме статьи? Если у вас негативный опыт с QA тимлидами, пропихнутыми на позицию их родственниками, это совсем не значит, что все QA лиды негодяи и оказались на своём месте незаслуженно.
И с чего Вы взяли что я про Вас что-то думаю? Я лишь постарался обратить внимание, что в статье приведены методы, которые будут полезны любому лиду. И имеет смысл хотя бы подумать как Вам это может помочь в работе, а не агриться на автора из-за его специализации.
> возможно там 40 разработчиков
Значит там минимум 4 лида, как того требует скрам
> который одинаково будет полезен любому тимлиду в любой сфере
Поднимать зп не по perfomance review, а по записочкам? Очень эффективно, наверно, но я воздержусь от таких нововведений у себя в команде.
> назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс,
То есть повесила свою ответственность на другого человека? Была бы разработчиком — сама бы контролировала (ведь это ее обязанность, представляете!)
> в разговоре 1:1 человеку куда проще озвучивать своё мнение
Конечно проще, ведь куашница, которая не шарит, не будет пытаться обьяснить где человек не прав, а просто выслушает и сделает еще одну записочку, углубляя проблему вместо ее решения.
> На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Еще как расскажет, если спросить его, почему он завалил спринт.
> Ни в статье, ни в комментах про пропихивание своих людей не упоминалось
Ну конечно, все вам об этом побежали рассказывать. А в реальности поставили управлять левого человека, не имеющего ни авторитета, ни компетенций, не посовещавшись с командой. Что это если не пропихивание своих людей?
Значит там минимум 4 лида, как того требует скрам
> который одинаково будет полезен любому тимлиду в любой сфере
Поднимать зп не по perfomance review, а по записочкам? Очень эффективно, наверно, но я воздержусь от таких нововведений у себя в команде.
> назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс,
То есть повесила свою ответственность на другого человека? Была бы разработчиком — сама бы контролировала (ведь это ее обязанность, представляете!)
> в разговоре 1:1 человеку куда проще озвучивать своё мнение
Конечно проще, ведь куашница, которая не шарит, не будет пытаться обьяснить где человек не прав, а просто выслушает и сделает еще одну записочку, углубляя проблему вместо ее решения.
> На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Еще как расскажет, если спросить его, почему он завалил спринт.
> Ни в статье, ни в комментах про пропихивание своих людей не упоминалось
Ну конечно, все вам об этом побежали рассказывать. А в реальности поставили управлять левого человека, не имеющего ни авторитета, ни компетенций, не посовещавшись с командой. Что это если не пропихивание своих людей?
Спасибо за такие развернутые комментарии! Действительно, я хотела донести до читателей лишь часть техник, которые помогают мне в работе каждый день, и могут помочь кому-то еще, особенно начинающим тимлидам
Да причём тут хрюша? Задача работать с людьми — на том, кто этих людей возглавляет. А то получается как обычно в IT: тимлидом назначают самого натасканного по теме интроверта-программиста, и далее до 50% уходит на miscommunication, обидки, перепрыгивания с проекта на проект и прочие прелести, которых сильно меньше в других отраслях
НЛО прилетело и опубликовало эту надпись здесь
Всегда можно заменить тимлида на нового, который никогда не видел продукт или разработку, и все сломать (с) возможно я был плохим тимлидом, а был техлидом. Как описано выше.
Думаю, тут позиция выше тимлида так же играет роль, нужен ли команде тимлид или просто руководитель хочет избавится/делегировать ответственность с себя.
Думаю, тут позиция выше тимлида так же играет роль, нужен ли команде тимлид или просто руководитель хочет избавится/делегировать ответственность с себя.
Вы не понимаете, просто надо было платить премии Петру за то что он выкатил говнобилд в пятницу, и хвалить Егора за то что он занимается автотестами вместо разработки критической функциональности проекта. А еще вы наверно не вели заметки о резко испортившемся настроении сотрудников и не общались с ними в интимной обстановочке 1 на 1, а решали все как настоящие технари на скрам-митингах.
> тут позиция выше тимлида так же играет роль,
Конечно, ведь лучший способ захватить власть — это поставить своих на правильные места. И пофиг, что компетенции не соответствуют :) Люди подобные Shoom3301 мне уже встречались, и объяснять им что кумовство к качеству продукта не приводит, — бесполезно, лучше просто расслабиться и смотреть как они сами себя закапывают своими решениями, ведь у этих решений, кроме как «есть разные подходы к орг. структуре.» других объяснений просто нет :)
> тут позиция выше тимлида так же играет роль,
Конечно, ведь лучший способ захватить власть — это поставить своих на правильные места. И пофиг, что компетенции не соответствуют :) Люди подобные Shoom3301 мне уже встречались, и объяснять им что кумовство к качеству продукта не приводит, — бесполезно, лучше просто расслабиться и смотреть как они сами себя закапывают своими решениями, ведь у этих решений, кроме как «есть разные подходы к орг. структуре.» других объяснений просто нет :)
Вы не понимаете, просто надо было платить премии Петру за то что он выкатил говнобилд в пятницу, и хвалить Егора за то что он занимается автотестами вместо разработки критической функциональности проекта. А еще вы наверно не вели заметки о резко испортившемся настроении сотрудников и не общались с ними в интимной обстановочке 1 на 1, а решали все как настоящие технари на скрам-митингах.Видел я такие встречи, и заметки видел. А потом видел как после этой интимной встречи, вся группа лишалась премии, потому что интимный разговор ничего не решил, и человек накосячил на следующий день. Скрам-митинги конечно хороши, но задачи и ее состояние доступны для всей команды(частный специфичный пример), тимлид в курсе всех задач и их статусов всегда. Заметки да, не вел, видно было по задачам, который брались но тормозились, и обидам, когда эти задачи переназначались другим.
Конечно, ведь лучший способ захватить власть — это поставить своих на правильные места. И пофиг, что компетенции не соответствуют :)Руководитель убирает тимлида с экспертизой и заменяет его чуваком с улицы, и берет еще двух помощников себе. Зато тимлид не спорит, а выполняет распоряжения, собирает встречи 1 на 1, делает заметки о настроении и еще наверное что то, в рамках компетенции. Тех. дир. офигивает от всего, но его руки связаны.
Лучше просто расслабиться и смотреть как они сами себя закапывают своими решениямиПо факту так и вышло. Команда развалилась, начальник получает писульки про эффективность. Решение задач без педалирования больше не получить, а может времени на это нет, после ежедневных проговариваний задач на встрече с лидом и тщательного конспектирования. Тимлид то без экспертизы, ему только заметки делать успевать :)
Видимо, это бич крупных компаний — появление начальников — самодуров, которые думают что они изобрели что-то новое, нарушая установленные не ими правила игры, а в реальности — просто собирают грабли, очевидные для прочих.
Кажется, вы слишком буквально восприняли примеры, которые приведены в документе-образце :) Не было там заложено столько негативного смысла, сколько вы здесь напридумывали.
В статье нигде не указано, что тимлид занимается только ведением этих заметок. Суть как раз в том, что, если фиксировать информацию вовремя, то можно потом экономить время. Вести такие записи несложно, их нужно делать в моменте.
Поверьте, сама деятельность тимлида — это не ведение заметок. Очень жаль, что вы так думаете.
Как я отметила выше, здесь говорится лишь об одном аспекте — работа с людьми, она не занимает 100% моего времени. И приведен лишь один инструмент, которым можно пользоваться
В статье нигде не указано, что тимлид занимается только ведением этих заметок. Суть как раз в том, что, если фиксировать информацию вовремя, то можно потом экономить время. Вести такие записи несложно, их нужно делать в моменте.
Поверьте, сама деятельность тимлида — это не ведение заметок. Очень жаль, что вы так думаете.
Как я отметила выше, здесь говорится лишь об одном аспекте — работа с людьми, она не занимает 100% моего времени. И приведен лишь один инструмент, которым можно пользоваться
Расскажите пожалуйста как вы завоевали авторитет команды которой руководите. Или это лишнее?
Привет, ну, например, подчинённый хочет увеличения з/п. У него есть непосредственный руководитель (обычно это тимлид), который, так же обычно, не имеет прямого доступа к фонду оплаты, он лишь может давать рекомендации вышестоящему руководству, что данному сотруднику необходимо выдать повышение. В статье как раз про это идёт акцент, что под рукой сразу будут доступны какие-то достижения сотрудника, если фиксировать их по факту поступления (приведённые в статье примеры мне самому не нравятся, но смысл достаточно передан). Если таких заметок нет, то надо будет что-то доставать из памяти, и, опять же, это указано, за всеми не запомнишь, что-то забудешь, да и на восстановление истории событий при отсутствии заметок уйдёт какое-то лишнее время.
Тут, на самом деле идёт торговля, тимлид торгуется за своего подчинённого и должен делать это хорошо, тогда, несомненно, авторитет будет расти. Видно, что у такого тимлида есть команда, за которую он переживает и решает подобного рода вопросы.
Так же, практически в каждой компании есть какие-либо подведения итогов. Пусть даже раз в год перед новым годом. Не надо тратить время на сбор информации, достаточно бегло оглядеть такие записи и можно сказать несколько приятных слов, какие ребята молодцы, выделив наиболее интересные или сложные решения, которые удалось реализовать. Таким образом видно, опять же, что этот менеджер печётся о своих подчинённых, ничего не забывает, то есть они работают не напрасно. Это приятно и это, несомненно, увеличивает авторитет.
Так же и увеличивает авторитет тимлида в глазах руководства, так как может сказать коротко и по делу, с аргументами, чем занимается его команда и почему они молодцы, в сравнении с другим тимлидом, который обычно скажет что-то вроде «год был тяжёлый, кто дожил до конца, тот молодец».
Эти довольно простые советы всего лишь вести своевременные заметки очень полезны в первую очередь тимлидам, которые вышли из технических специалистов и даже не задумываются, что теперь всё то, что я написал выше, лежит на их хрупких плечах, так как в явном виде они никогда и нигде не прописаны, но через какое-то время всегда всплывают. И если новоиспечённый руководитель будет к ним готов, это показатель, что он справляется со своей работой на отлично, что так же повышает авторитет )
Тут, на самом деле идёт торговля, тимлид торгуется за своего подчинённого и должен делать это хорошо, тогда, несомненно, авторитет будет расти. Видно, что у такого тимлида есть команда, за которую он переживает и решает подобного рода вопросы.
Так же, практически в каждой компании есть какие-либо подведения итогов. Пусть даже раз в год перед новым годом. Не надо тратить время на сбор информации, достаточно бегло оглядеть такие записи и можно сказать несколько приятных слов, какие ребята молодцы, выделив наиболее интересные или сложные решения, которые удалось реализовать. Таким образом видно, опять же, что этот менеджер печётся о своих подчинённых, ничего не забывает, то есть они работают не напрасно. Это приятно и это, несомненно, увеличивает авторитет.
Так же и увеличивает авторитет тимлида в глазах руководства, так как может сказать коротко и по делу, с аргументами, чем занимается его команда и почему они молодцы, в сравнении с другим тимлидом, который обычно скажет что-то вроде «год был тяжёлый, кто дожил до конца, тот молодец».
Эти довольно простые советы всего лишь вести своевременные заметки очень полезны в первую очередь тимлидам, которые вышли из технических специалистов и даже не задумываются, что теперь всё то, что я написал выше, лежит на их хрупких плечах, так как в явном виде они никогда и нигде не прописаны, но через какое-то время всегда всплывают. И если новоиспечённый руководитель будет к ним готов, это показатель, что он справляется со своей работой на отлично, что так же повышает авторитет )
Не знаю, что так в комментариях агрятся на автора. Да, ребята, вы можете считать, что тимлид обязан иметь определённый набор функциональных обязанностей. Но по факту, в разных компаниях обязанности сильно различаются. Обычно, чем меньше компания, тем больше функций ложиться на плечи тимлида. И вот недавний технический специалист, отработав полгода тимлидом (повторяю, он может называться архитектором, руководителем разработки или отдела, оно всё тимлид), в общем, начинают прилетать разного рода вопросы, типа кто-то хочет з/п себе поднять из подчинённых, либо начальник говорит: «мне вышестоящий начальник сказал отчёт дать, что там в вашем проекте творится (не придирайтесь только к словам, пожалуйста, тут надо читать так: пришлите наиболее интересные моменты, что вы реализовали за пол года)», и это нормально, что вышестоящий не разбирается во всех аспектах и тонкостях. Да, надо лезть в жиру, пробегаться, фильтровать задачи, достать всё можно, но при наличии таких записей на оформление письма уйдёт 20 минут, а при ковырянии хистори потратится несколько часов.
И с зарплатой подчинённого, с такими заметками сразу есть аргументы для вышестоящего руководства, какие важные/полезные штуки реализовал этот самый подчинённый и почему ему необходимо повысить зарплату. Вместо мычания «ну он там работал что-то норм, делает свои задачи», 10 минут беглого осмотра и есть ясные факты, которые с последнего грейда за всех ребят запомнить невозможно
В общем, советы в статье даны дельные, вести заметки по таким вещам заблаговременно не составит труда, но даст много реальной пользы и поднимет профессионализм тимлида в глазах вышестоящего руководства.
И с зарплатой подчинённого, с такими заметками сразу есть аргументы для вышестоящего руководства, какие важные/полезные штуки реализовал этот самый подчинённый и почему ему необходимо повысить зарплату. Вместо мычания «ну он там работал что-то норм, делает свои задачи», 10 минут беглого осмотра и есть ясные факты, которые с последнего грейда за всех ребят запомнить невозможно
В общем, советы в статье даны дельные, вести заметки по таким вещам заблаговременно не составит труда, но даст много реальной пользы и поднимет профессионализм тимлида в глазах вышестоящего руководства.
Не осуждаю вашего подхода, однако есть вопросы, например:
Как у вас в команде происходит анализ и принятие решений по приоритетам задач бэклога?
Что вы делаете, когда команда делится на два лагеря по принятию решения и все настаивают на своем?
Как у вас в команде происходит анализ и принятие решений по приоритетам задач бэклога?
Что вы делаете, когда команда делится на два лагеря по принятию решения и все настаивают на своем?
Не отвечу за Киру, скажу как в моей команде — есть бизнес-аналитик, он же технолог, который приносит задачу в команду и расставляет им приоритеты. В соответствии с этими приоритетами задачи и забираются в работу. Предполагаю, что у Киры что то похожее.
Делается сбор, каждый рассказывает почему он за свой вариант и чем не нравится другой. Путем общего разбора проблема решается. Тот важно, что бы никто не ушел расстроенным/обиженным.
Что вы делаете, когда команда делится на два лагеря по принятию решения и все настаивают на своем?
Делается сбор, каждый рассказывает почему он за свой вариант и чем не нравится другой. Путем общего разбора проблема решается. Тот важно, что бы никто не ушел расстроенным/обиженным.
Когда-то давно была статься Что должен делать тимлид: роли, обязанности и навыки. Уж очень мне там схема понравилась по компетенциям. И уж очень разные вещи в компаниях являются основными для team lead-а. Было бы интересно прочитать о том, что наиболее востребовано на вашем месте работы, какие обязянности в приоретете.
Да, действительно, обязанности тимлидов в разных компаниях очень отличаются. Многое зависит от специфики команды и от количества людей в ней. Как минимум, тимлид должен выстраивать процессы работы, тесно взаимодействовать с людьми и выстраивать межкомандные взаимодействия. Статья, которую вы привели, правда замечательная, роадмап удобный — пригодится на все случаи жизни. И он давно у меня в закладках :)
Спасибо за статью, интересно. Можете поподробнее рассказать о "Планах развития"? Как у вас происходит процесс составления целей для pdp? От чего вы идете, только от интереса и желания самого сотрудника, или от карты компетенций? Что вы делаете если интересы сотрудника, в рамках pdp расходятся c задачами и областью в которой он работает? И насчет самого процесса работы по pdp — это добровольно, или принудительно? Может ли сотрудник выделить процент из рабочего время на pdp? Заранее спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметки тимлида