Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Единственное что могу заметить… Что часто когда пытаются внедрить Agile / scrum пытаются сопоставить роли PM, тимлида и т.п. Так вот тимлидов и PM в Scrum НЕТ!!!
Да, очень часто сталкиваюсь с таким миксом из должностей и ролей. Отсюда же рождение должностей Scrum Master, Product Owner. Причем под Product Owner кого только не поразумевают от системного аналитика до менеджера продукта.
Да да) Дело в том что культура предприятия должна учитывать Agile ценности и изменяться, а не натягивать часть техник на существующие роли и процесс. Вчера очень понравился доклад Дмитрия Лобасева «Модель Agile-трансформации крупной компании или когда Scrum бессилен»
Так же рекомендую Keynote: Agile is Dead by Pragmatic Dave Thomas
Не скрамом единым. К тому же он не запрещает назначать другие роли вне каркаса скрама.
Чем больше ролей — тем больше можно раздать медалек и выделить кого нибудь, чтобы не сбежал. Хехе.
Чем больше ролей — тем больше можно раздать медалек и выделить кого нибудь, чтобы не сбежал. Хехе.
Может дешевле доску почета передовиков производства завести!?)
Бывает даже, что дешевле поднять зарплату. Разные бывают механизмы мотивации. Я их не предлагаю, всего лишь говорю о том, что имеет место быть в реальности.
Перепутать тимлида и пипл менеджера, как сделал автор, это не самое худшее. Нередко позиция тимлида — просто механизм задержать крутого спеца подольше в команде.
Перепутать тимлида и пипл менеджера, как сделал автор, это не самое худшее. Нередко позиция тимлида — просто механизм задержать крутого спеца подольше в команде.
В общем, получается, что тимлид это гораздо больше менеджер, чем программист.
Зависит от команды, если команда я, да Вася, то на управление времени не уйдет почти нисколько, но когда команда переваливает за 5 человек на управление уже уходит большая часть времени. А в команды более 10 человек я вообще не верю, они неуправляемы.
По мне Ваше утверждение так же справедливо как, например, «Программист, получается, больше наборщик текстов». В статье очень хорошо обозначены обязанности тимлида, и объем управленческих работ предлагается приемлемый.
Ну и странный же вывод. Если бы вы внимательно прочитали статью, то увидели бы — там описано, что основная обязанность тимлида именно управлять командой. А непосредственно программирование — это второстепенно. А управление — это менеджмент. Не знаю, что тут может быть непонятно.
Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.
И если менеджменту уделить процентов 15-20, то это приемлемо. Тимлид все же программист (у команды разработчиков, конечно), и это совсем не ПМ. Не знаю, интересно ли Вам мое собственное мнение, если да, то оно за
спойлом
(далее личный опыт исключительно) Все эти управленческие дела при правильном подходе не напрягают… Я и раньше, например, помогал более слабым членам команд в решении проблем, если они в этом нуждались (еще не будучи на позиции тимлида). Добавить к этому распределение задач? Легко, мы используем довольно эффективный метод оценки временных затрат, которому обучены так же и члены команды. Остаются только коммуникации, но с этим вообще проблем не было никогда. Остается только «умение завоевать авторитет» — но это вышло естественным путем, когда не «выпрыгиваешь из штанов» тебя лишняя порция ответственности не напрягает.
(далее личный опыт исключительно) Все эти управленческие дела при правильном подходе не напрягают… Я и раньше, например, помогал более слабым членам команд в решении проблем, если они в этом нуждались (еще не будучи на позиции тимлида). Добавить к этому распределение задач? Легко, мы используем довольно эффективный метод оценки временных затрат, которому обучены так же и члены команды. Остаются только коммуникации, но с этим вообще проблем не было никогда. Остается только «умение завоевать авторитет» — но это вышло естественным путем, когда не «выпрыгиваешь из штанов» тебя лишняя порция ответственности не напрягает.
Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.
То что вам показалось значимым — это как раз пример дополнительных обязанностей, который привел автор статьи. Из того же абзаца (никакого субъективизма, все из статьи):
… это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно…
… согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
То что вам удается обходиться 15% времени на менеджмент — это замечательно. Но, если команда состоит из средненьких программистов, среди которых есть люди с проблемным характером, да еще и руководство компании непростое и любит долгие совещания (и на каждое дергает тимлида), плюс добавим кучу мелких администратвных дел, которые могут быть повешены на тимлида, то тут хорошо, если хотя бы 40% времени останется на непосредственно программирование.
Не даром же на западе в некоторых командах есть отдельно технический лидер (который полностью отвечает за техническую сторону, архитектуру) и тимлид (который больше менеджер).
Ваш личный опыт прочесть было интересно, но я думаю, сколько людей, столько и мнений.
40% времени останется на непосредственно программирование.
У меня был опыт работы на проектах и в условиях, где и простому разработчику приходилось тратить по 2-3 часа в день на митинги. Это проблема процессов внутри компании а не конкретных должностей. Вы собственно сами об этом указали. Но если в этих митингах не видно ценности, то может быть имеет смысл поговорить с руководством и как-то оптимизировать процесс? Есть правда еще бюрократия но…
К счастью, я еще не встречал команд, где обычных разработчиков выдергивают каждый день на 3 часа на митинги) Это, должно быть, очень богатые компании, если могут себе такое позволить =)
По поводу тимлида, штука вот в чем (из статьи):
То есть, главное — это донести до команды задачу, правильно распределить ее между программистами и обеспечить выполнение, а не стараться отгородиться от всего, лишь бы сидеть и самому заниматься имплементацией.
Хорошо, сегодня тимлиду удалось оптимизировать митинги внутри компании, сократив их время на 50%, а завтра появятся подрядчики, с которыми тоже нужно проводить митинги. И тимлид закроет свою IDE и пойдет это делать. Потому что управление для него приоритетней, чем непосредственно программинг.
По поводу тимлида, штука вот в чем (из статьи):
тимлид — интерфейс команды разработки
То есть, главное — это донести до команды задачу, правильно распределить ее между программистами и обеспечить выполнение, а не стараться отгородиться от всего, лишь бы сидеть и самому заниматься имплементацией.
Хорошо, сегодня тимлиду удалось оптимизировать митинги внутри компании, сократив их время на 50%, а завтра появятся подрядчики, с которыми тоже нужно проводить митинги. И тимлид закроет свою IDE и пойдет это делать. Потому что управление для него приоритетней, чем непосредственно программинг.
Потому что управление для него приоритетней, чем непосредственно программинг.
И это правильно, иначе он был бы просто программистом а не руководителем отдела разработки. Есть еще такие персонажи как техлиды, и они обычно кодят больше.
Ну вот. Из этого вывод, что если у тимлида на кодинг остается всего 30% (к примеру) от всего рабочего времени, это никакая не проблема, а просто особенность должности. И к этому надо быть готовым — не каждый программист хочет расти в таком направлении.
Я знаю один интересный прецедент, когда командой python-разработчиков (в рамках весьма крупной компании) руководил PHP разработчик. И там процент времени занятый кодом — 0%. Чисто управление командой, улучшение процесса разработки, собеседования и т.д. И ничего, все хорошо работали, процессы развивались и все такое. По хорошему тимлид вообще кодить не должен, но может. Но по итогу спустя два года (если память не изменяет) ему стало грустно от того что он не кодит.
> Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
А мне вот наоборот интересно было бы услышать у кого какие способы сплочения коллектива. Может традиции какие-то, пицца по пятницам?.. Рассказывайте, очень интересно услышать! :)
По теме:
Сам я тимлид, свою миссию вижу именно как помочь команде комфортно, профессионально и в сроки выполнять задачи. А так же давать PM'y оценку работ и консультировать по всевозможным техническим вопросам. И да, я пишу много кода, рисую интерфейсы, выдумываю архитектуру и много еще всего, хотелось бы делать этого меньше, но пока никак :)
А мне вот наоборот интересно было бы услышать у кого какие способы сплочения коллектива. Может традиции какие-то, пицца по пятницам?.. Рассказывайте, очень интересно услышать! :)
По теме:
Сам я тимлид, свою миссию вижу именно как помочь команде комфортно, профессионально и в сроки выполнять задачи. А так же давать PM'y оценку работ и консультировать по всевозможным техническим вопросам. И да, я пишу много кода, рисую интерфейсы, выдумываю архитектуру и много еще всего, хотелось бы делать этого меньше, но пока никак :)
Про тимбилдинг говорить не хотел, так как сам не специалист и не верю в него.
По крайней мере в тот, который по инициативе администрации организуется.
Тимлид, кстати, тоже как часть администрации воспринимается, и от его лица тимбилдинги проводить тоже плохая идея.
Есть тонкий момент в том, что просьба со стороны уважаемого командой тимлида для многих равносильна указанию.
Но когда речь идет о добровольных мероприятиях тимлиду некоторым отказать сложно, и уже не понять, по доброй ли воле идет сотрудник на мероприятие.
Хорошая идея взять в команду душу компании, который(ая) будет перехватывать инициативу во внерабочее время, это работает.
Мероприятия практикуют самые разные, просто пойти в бар, с гитарой на лужайку, в ЧГК сыграть (https://igry-razuma-intellektual.timepad.ru/events/), играют и в покер и настольные игры, катаются на велосипедах.
Но лично у меня есть сомнения, что переход в отношениях из коллег в друзья-товарищи играет большую роль в «повысить эффективность взаимодействия между членами команды» — потому и написал в кавычках. Считаю, что больший выигрыш в таком переходе у компании, за счет которого она крепче привязывает к себе сотрудников.
По теме, у вас вполне стандартный набор обязанностей, может в вашем случае их передача кому-то и необоснована?
По крайней мере в тот, который по инициативе администрации организуется.
Тимлид, кстати, тоже как часть администрации воспринимается, и от его лица тимбилдинги проводить тоже плохая идея.
Есть тонкий момент в том, что просьба со стороны уважаемого командой тимлида для многих равносильна указанию.
Но когда речь идет о добровольных мероприятиях тимлиду некоторым отказать сложно, и уже не понять, по доброй ли воле идет сотрудник на мероприятие.
Хорошая идея взять в команду душу компании, который(ая) будет перехватывать инициативу во внерабочее время, это работает.
Мероприятия практикуют самые разные, просто пойти в бар, с гитарой на лужайку, в ЧГК сыграть (https://igry-razuma-intellektual.timepad.ru/events/), играют и в покер и настольные игры, катаются на велосипедах.
Но лично у меня есть сомнения, что переход в отношениях из коллег в друзья-товарищи играет большую роль в «повысить эффективность взаимодействия между членами команды» — потому и написал в кавычках. Считаю, что больший выигрыш в таком переходе у компании, за счет которого она крепче привязывает к себе сотрудников.
По теме, у вас вполне стандартный набор обязанностей, может в вашем случае их передача кому-то и необоснована?
Я тимлид и, в отличие от предыдущего оратора, верю в тимбилдинг. К сожалению, моя компания не оплачивает такие штуки, поэтому приходится изобретать самому. У меня психологическое образование, так что мне, вероятно, немного легче.
Я считаю, что хорошая команда складывается, когда с одной стороны, все разбираются в некой широкой доменной области, а с другой ещё и в какой-то своей узкой. Соответстенно в час нужды все всем могут помочь и все знают к кому можно обратиться за помощью. Я, как тимлид, снимаю компетенции со всех и могу помочь кому угодно — и стараюсь делать это по мере необходимости. Удивительно н алюдей действует ощущение того, что их коллега может помочь решить почти любую проблему. Они становятся открытыми, с радотью изучают новое и помогают друг другу.
Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.
Рядом с такими непонятными и неформальными вещами, как ни странно отлично уживаются кодревью, мёрджреквесты (только сейчас к ним пришли, к сожалению, надо было раньше) и другие штуки, которые помогают нам следить за качеством кода друг друга. Надо сказать, что холивары тоже случаются — их помогает решить либо демократия, либо диктатура — к счастью, тимлид может выбирать любую модель в зависимости от ситуации. Диктатура может быть актуальна в том случае, если тимлид больше знает об итоговых целях чем команда — так тоже бывает. Очень часто разработчиков не особенно интересуют глобальные цели, а больше интересуют локальные задачи. Это нормально и к ним надо относиться с пониманием — не все обладают имперскими амбициями.
Да, понимание — это тоже отличная штука, которая помогает создать команду. В атмосфере понимания кодревью проходят гладко, ошибки правятся быстрее и зачастую лучше. Все понимают, что замечание — это не желание придраться, а желание добиться лучшей цели.
Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл :)
Ещё важная лично для меня вещь — это эмпатия, то есть способность хорошо воспринимать эмоции окружающих. Может кто-то считает это выдумкой, а кто-то считает, что эмоциям на работе не место, но я в эти концепции не верю. Я считаю, что понимание эмоций команды ведёт к тому, что никто никого не доведёт до такой вспышки эмоций, каковая помешает ему работать. С эмоциями надо уметь работать, да.
P.S. Не бейте больно, это просто мой, причём не очень большой, опыт. Ваш может быть частично или совсем другим.
Я считаю, что хорошая команда складывается, когда с одной стороны, все разбираются в некой широкой доменной области, а с другой ещё и в какой-то своей узкой. Соответстенно в час нужды все всем могут помочь и все знают к кому можно обратиться за помощью. Я, как тимлид, снимаю компетенции со всех и могу помочь кому угодно — и стараюсь делать это по мере необходимости. Удивительно н алюдей действует ощущение того, что их коллега может помочь решить почти любую проблему. Они становятся открытыми, с радотью изучают новое и помогают друг другу.
Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.
Рядом с такими непонятными и неформальными вещами, как ни странно отлично уживаются кодревью, мёрджреквесты (только сейчас к ним пришли, к сожалению, надо было раньше) и другие штуки, которые помогают нам следить за качеством кода друг друга. Надо сказать, что холивары тоже случаются — их помогает решить либо демократия, либо диктатура — к счастью, тимлид может выбирать любую модель в зависимости от ситуации. Диктатура может быть актуальна в том случае, если тимлид больше знает об итоговых целях чем команда — так тоже бывает. Очень часто разработчиков не особенно интересуют глобальные цели, а больше интересуют локальные задачи. Это нормально и к ним надо относиться с пониманием — не все обладают имперскими амбициями.
Да, понимание — это тоже отличная штука, которая помогает создать команду. В атмосфере понимания кодревью проходят гладко, ошибки правятся быстрее и зачастую лучше. Все понимают, что замечание — это не желание придраться, а желание добиться лучшей цели.
Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл :)
Ещё важная лично для меня вещь — это эмпатия, то есть способность хорошо воспринимать эмоции окружающих. Может кто-то считает это выдумкой, а кто-то считает, что эмоциям на работе не место, но я в эти концепции не верю. Я считаю, что понимание эмоций команды ведёт к тому, что никто никого не доведёт до такой вспышки эмоций, каковая помешает ему работать. С эмоциями надо уметь работать, да.
P.S. Не бейте больно, это просто мой, причём не очень большой, опыт. Ваш может быть частично или совсем другим.
Спасибо за то, что поделились, очень интересны разные точки зрения.
Мое недоверие направлено скорее на то, как тимбилдинг реализуется на практике, похоже на карго-культ, тимбилдинг ради тимбилдинга.
Доверие и взаимопомощь неплохо развиваются и при повседневной работе, если обстановка в коллективе к тому располагают, если же нет — никакие специальные мероприятия этому не помогут.
На практике же часто бывает так, что на работе у нас каждый сам за себя, причем именно руководство создает такую обстановку, а потом, внезапно, на специальном мероприятии, специально обученные люди (внутренние или внешние), за деньги внушают коллективу, что они — команда.
Такой тимбилдинг мне не по душе.
Лучше всего, когда инициатива командообразования рождается и поддерживается внутри команды, причем лучше когда это происходит не по инициативе администрации.
Мое недоверие направлено скорее на то, как тимбилдинг реализуется на практике, похоже на карго-культ, тимбилдинг ради тимбилдинга.
Доверие и взаимопомощь неплохо развиваются и при повседневной работе, если обстановка в коллективе к тому располагают, если же нет — никакие специальные мероприятия этому не помогут.
На практике же часто бывает так, что на работе у нас каждый сам за себя, причем именно руководство создает такую обстановку, а потом, внезапно, на специальном мероприятии, специально обученные люди (внутренние или внешние), за деньги внушают коллективу, что они — команда.
Такой тимбилдинг мне не по душе.
Лучше всего, когда инициатива командообразования рождается и поддерживается внутри команды, причем лучше когда это происходит не по инициативе администрации.
В качестве тимлида — главная тема из шуток по сроки «выпустить в продакшен проект самому за две недели, если все пошло в пропасть». А в целом, нужно не знать абсолютно все, а уметь помочь и подсказать в каком направлении «копать» по проекту. Сейчас в планах проводить командные тренинги в неформальной обстановке, когда видишь, что человек не умеет достаточно хорошо пользоваться каким-то инструментом: git, ide, браузерные dev-tools и т.п…
И, кстати, да. У нас укрепилась традиция уже на протяжении трех лет — пицца по четвергам.
И, кстати, да. У нас укрепилась традиция уже на протяжении трех лет — пицца по четвергам.
Пицца по пятницам очень-очень легко вырождается в «Нафиг мы собрались? А, ну да, пиццу поесть и только.»
Есть ещё одна сторона медали в работе тимлида — обратная связь команде. Без обратной связи люди не понимают, в том ли направлении они движутся. Это правда важно.
Когда обратная связь положительная (ну или хотя бы нейтральная), то всё ок. Хотя и тут стоит не перестараться (:
А вот когда она отрицательная, это чертовски сложно. Причём в каждой отдельно взятой ситуации сложно по-своему.
С тимбилдингами всё не просто. Особенно когда в команде пара интровертов, что в нашей отрасли встречается чуть чаще среднего, и семейные с детьми.
Когда обратная связь положительная (ну или хотя бы нейтральная), то всё ок. Хотя и тут стоит не перестараться (:
А вот когда она отрицательная, это чертовски сложно. Причём в каждой отдельно взятой ситуации сложно по-своему.
С тимбилдингами всё не просто. Особенно когда в команде пара интровертов, что в нашей отрасли встречается чуть чаще среднего, и семейные с детьми.
Обратная связь очень важна в работе тимлида, я отношу ее к инструментам поддержания и развития компетенции, а в некоторых случаях и поддержания настроений в команде.
Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.
Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.
Очень хорошая статья. Наверное, лучше и не опишешь. К слову про Scrum: возможно кто-то и играет в Scrum без тимлидов, но это создает некоторые проблемы.
Спасибо, всегда можно сделать лучше, было бы время.
Мои изучения Scrum'а и допытывания всяких гуру привели меня к выводу, что для Scrum'а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
Мои изучения Scrum'а и допытывания всяких гуру привели меня к выводу, что для Scrum'а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
кто-то играет в скрам без скрам-мастера, в этом проблема, а тимлиды это архаизм, но для небольших проектов годится, немного знает методики управления, немного программирует, способен немного натаскать джунов, но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
Фундаментальное различие в том, что в скрам-мастер фокусирует команду на результате (скрам — это жестко прописанные роли, правила и артефакты), тогда как тимлид сам распыляется и не может сфокусировать и четко объяснить свою деятельность, не говоря уже о команде (даже в интернете все пытаются по разному формализавать, и изобретать чем же он занимается).
но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают, а то, признаться, я таких за 10+ лет опыта не видел, что-то новое и неоткрытое! :)
О это обширная тема, я наверно буду на пенсии писать про это мемуары, начиная о том как «тимлиды» предлагали писать в коде сервера компоненты для фронтенда, и заканчивая тезисами о монолитной разработке вместо модульной (loosely coupled), плюс всякие пулл реквесты висящие днями на рассмотрении в то время как дедлайн и проект горит. А также как предлагая лучшие практики, получаешь ответы лида типа «у нас это не принято». Или о приватных звонках «тимлидов», с просьбами срочно прекратить разработку и тестирование продукта, вместо того чтобы обсудить все в общем чате со всей командой. И о проектах, которые поднимались из руин за полгода-год, которые факапились около трех лет «опытным тимлидом» с командой разработчиков. Ладно если бы это была случайность и один проект, но это разные проекты, и повсеместно особенно на фрилансе.
Тимлид
1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
принимает в разработке активное участие.
2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
(друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
внезапно, может быть несколько активных спринтов, команда не принимает участия в
формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
поддается прогнозированию.
4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
проблемы никого не интересуют.
5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
и тесно взаимосвязано. (tightly coupled).
6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
и затрат времени на это.
7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
8) Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
задачи появляются неожиданно.
9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
без работы.
Знакомые ситуации?
1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
принимает в разработке активное участие.
2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
(друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
внезапно, может быть несколько активных спринтов, команда не принимает участия в
формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
поддается прогнозированию.
4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
проблемы никого не интересуют.
5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
и тесно взаимосвязано. (tightly coupled).
6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
и затрат времени на это.
7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
8) Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
задачи появляются неожиданно.
9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
без работы.
Знакомые ситуации?
Давайте, я отвечу такой аналогией.
У меня есть велосипед — у него отвалилось колесо.
Он был покрашен — краска стала отходить.
Проехав 10 километров, он заскрепел, т.к. не был смазан, а после 20-ти километров появился люфт руля.
Вывод: все велосипеды — зло!
Так и вас: вы приводите нормальные поинты, только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов.
У меня есть велосипед — у него отвалилось колесо.
Он был покрашен — краска стала отходить.
Проехав 10 километров, он заскрепел, т.к. не был смазан, а после 20-ти километров появился люфт руля.
Вывод: все велосипеды — зло!
Так и вас: вы приводите нормальные поинты, только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов.
только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов
Эту работу как раз и организует лид, постоянно создавая команде проблемы. Если конечно в ней не джуны, ничего не понимающие, и не видевшие.
Все бы так, да в скраме так не забалуешь, там быстро все выводится на чистую воду), потому как в скраме открытые обсужения и абсолютная прозрачность, что лидам вообще не в масть (которым надо постоянно позиционировать свое менторство, и не дай бог в команде кто то появится, более сведующий, которой постоянно «дискредитирует лида» своими предложениями, и по-тихому убирается из проекта). Лид не нужен совсем, нет в скраме такой роли. Вот и в таких статьях и постоянно выдумывают чем же заниматься лидам. А аналогия не в тему и не логична, можно все что угодно приплесть и машину и ракету и холодильник и т.п.
Тимлид держится за место на проекте, но не за сам проект, он скорее завалит проект, чем согласится перейти на скрам, и ликвидировать эту роль.
Это ограниченное понимание роли лида, притянутое за уши опыта, через который вы прошли. Повторюсь: не стоит путать свойство функции со свойством исполнителя этой функции. Если, к примеру, вам только и встречались лиды, которые были «дискредитированы» более «сведущими», то это не значит, что все лиды такие :)
Если с Скраме нет какой-то вещи, то это не значит, что она не нужна!
Если в Скраме нет роли лида, то это не значит, что никто не исполняет эту роль!
Лид не нужен совсем, нет в скраме такой роли.
Если с Скраме нет какой-то вещи, то это не значит, что она не нужна!
Если в Скраме нет роли лида, то это не значит, что никто не исполняет эту роль!
Круг замкнулся,
Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают
Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
Как говорится почувствуйте разницу
Скрам
1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
менятся как дежурный.
2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
возникновения, а планируются на следующие спринты). При серьезном подходе можно
рассчитать выход продукта и обновлений.
4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
(loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
сущностей. Выявлятся и устраняются причины багов.
7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
находит таск и перечитывает контекст задачи.
8) Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
переход на другой проект или время на обучение.
Скрам
1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
менятся как дежурный.
2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
возникновения, а планируются на следующие спринты). При серьезном подходе можно
рассчитать выход продукта и обновлений.
4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
(loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
сущностей. Выявлятся и устраняются причины багов.
7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
находит таск и перечитывает контекст задачи.
8) Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
переход на другой проект или время на обучение.
Очень понравилась статья, ибо похоже на собственную жизненную ситуацию:
я тимлид в аутстафф команде разработки, и как раз-таки являюсь тем самым фронтэндом между руководством (в другом городе, общение скайп+почта) и нашей командой. Распределяю задачи, оцениваю возможности и личностные качества отдельных членов команды, помогаю с вопросами и принятиями решений (помогает бо'льший опыт взаимодейтсвия с дорабатываемой системой). Ну и заинтересованность повыше, конечно… В общем, очень хорошо Ваша концепция ложится на мои реалии, респект!
я тимлид в аутстафф команде разработки, и как раз-таки являюсь тем самым фронтэндом между руководством (в другом городе, общение скайп+почта) и нашей командой. Распределяю задачи, оцениваю возможности и личностные качества отдельных членов команды, помогаю с вопросами и принятиями решений (помогает бо'льший опыт взаимодейтсвия с дорабатываемой системой). Ну и заинтересованность повыше, конечно… В общем, очень хорошо Ваша концепция ложится на мои реалии, респект!
И всё-таки остается загадкой: совершенствование процесса в команде — это основная или побочная обязанность тимлида? С одной стороны, команда сама должна вырабатывать «правила игры», но иногда для этого требуется «волшебный пинок».
«Совершенствование процесса в команде» — что вы имеете в виду?
Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
Можно вообразить частный случай для иллюстрации:
Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.
Это и есть одна из задач тимлида, как тимлида, другая деятельность, такая как проектирование, уточнение требований и прочее сотрудник осуществляет от лица других ролей.
Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
Можно вообразить частный случай для иллюстрации:
Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.
Это и есть одна из задач тимлида, как тимлида, другая деятельность, такая как проектирование, уточнение требований и прочее сотрудник осуществляет от лица других ролей.
Тимлид — это такой человек, который знает абсолютно все о проекте, у которого можно спросить любую вещь и он ответит. Который имеет видение проекта как в целом, так и в деталях, обладает определенной интуицией в способе решения поставленных задач.
В любом успешном проекте есть такой человек, и не обязательно в IT: главный конструктор, ведущий инженер, etc… Если в проекте нет такого человека — это показатель обреченности проекта. Как бы мы ни старались развивать колаборационные навыки, идея и интуиция не масштабируются и не могут функционировать распределенно во многих головах сразу.
В любом успешном проекте есть такой человек, и не обязательно в IT: главный конструктор, ведущий инженер, etc… Если в проекте нет такого человека — это показатель обреченности проекта. Как бы мы ни старались развивать колаборационные навыки, идея и интуиция не масштабируются и не могут функционировать распределенно во многих головах сразу.
Статья большая, а все очень просто. Тимлин — это человек способный организовать команду на реализацию заявленного продукта. Все остальное словоблудее. Нужно будет и огород копать пойдет. ))
Я с вами не согласен. Возможно попытки формализовать что такое тимлид в разработке обречены на провал. Но то, что вы описали — это пипл менедмент.
Он должен суметь сделать так, чтобы каждый член команды справлялся с поставленными перед ним задачами. Для этого нужно, чтобы:
члены команды были согласны выполнять поручения,
достаточно компетентны для этого,
обладали достаточными ресурсами (в первую очередь — временем),
могли ужиться вместе.
В крупных компаниях этим занимаются пипл менеджеры. И это целая наука. Не нужно быть лидером, чтобы обеспечивать все эти пункты. Они в принципе не имеют отношения к лидерству.
Лидерство — в психологии процесс социального влияния, благодаря которому лидер получает поддержку со стороны других членов сообщества для достижения цели.
Вот и все. Тимлид — это человек, который в силу каких то причин (своей компетенции, позиции в компании или доверию менеджмента) получает поддержку от команды, что дает ему в руки инструмент влияния на эту команду. Этот инструмент влияния может быть потрачен на цели пипл менеджмента или на цели проектного менеджмента. Но это совершенно не означает, что тимлид автоматически становится пипл или проджект менеджером. Или должен им быть.
Конечно часто в компании тимлид может объединять разные роли. Но не надо придумывать новые определения для этого термина сужая его изначальные рамки. Так вы автоматически уходите от реальности.
Он должен суметь сделать так, чтобы каждый член команды справлялся с поставленными перед ним задачами. Для этого нужно, чтобы:
члены команды были согласны выполнять поручения,
достаточно компетентны для этого,
обладали достаточными ресурсами (в первую очередь — временем),
могли ужиться вместе.
В крупных компаниях этим занимаются пипл менеджеры. И это целая наука. Не нужно быть лидером, чтобы обеспечивать все эти пункты. Они в принципе не имеют отношения к лидерству.
Лидерство — в психологии процесс социального влияния, благодаря которому лидер получает поддержку со стороны других членов сообщества для достижения цели.
Вот и все. Тимлид — это человек, который в силу каких то причин (своей компетенции, позиции в компании или доверию менеджмента) получает поддержку от команды, что дает ему в руки инструмент влияния на эту команду. Этот инструмент влияния может быть потрачен на цели пипл менеджмента или на цели проектного менеджмента. Но это совершенно не означает, что тимлид автоматически становится пипл или проджект менеджером. Или должен им быть.
Конечно часто в компании тимлид может объединять разные роли. Но не надо придумывать новые определения для этого термина сужая его изначальные рамки. Так вы автоматически уходите от реальности.
Спасибо за ваше мнение!
Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
Я говорю о линейных менеджерах, к которым прикреплены люди. Которым непосредственно репортят. Которые решают проблемы мотивации сотрудников и их развитием в компании. Это не тоже самое, что проектный менеджмент.
Внутренние отношения в командах — это управление людьми. Управление людьми и лидерство — это не одно и тоже. Я понимаю, что можно легко взять какой то термин и начать придумывать для него определение. Вот только зачем?
В моем понимании если человек позиционирует себя как тимлид — значит от него ожидается, что он способен вызвать доверие команды и своим авторитетом повлиять на ее мнение для того, чтобы можно было решать проблемы управления людьми или проектами.
А менеджер (руководитель) как раз имеет компетенцию, для того, чтобы эти проблемы решать опираясь на доверие команды к лидеру.
Именно поэтому тимлид — это почти всегда самый опытный инженер для данного конкретного проекта для данной команды. Или самый ответственный. И редко так бывает, что тимлид обладает специальными знаниями в области управления людьми. Следовательно профессионально решать такие проблемы он не сможет.
Ну… я говорю о роли конечно, а не о человеке. На одном человеке может быть много ролей.
В командах профессионалов (не в какой то технологии, а в принципе) тимлиды обычно просто не нужны. Потому, что люди и сами могут согласовывать решения и работу. В таком случае ресурс лидерства-подчинения, предоставляемый тимлидами, просто перестает быть нужен для менеджеров. Если же команда согласовываться не в состоянии, то из нее выделяют лида.
Но какой то специальной профессии тимлид нет. Человек просто может быть тимлидом в данной конкретной ситуации. А профессия менеджера (который управляет людьми) есть.
Внутренние отношения в командах — это управление людьми. Управление людьми и лидерство — это не одно и тоже. Я понимаю, что можно легко взять какой то термин и начать придумывать для него определение. Вот только зачем?
В моем понимании если человек позиционирует себя как тимлид — значит от него ожидается, что он способен вызвать доверие команды и своим авторитетом повлиять на ее мнение для того, чтобы можно было решать проблемы управления людьми или проектами.
А менеджер (руководитель) как раз имеет компетенцию, для того, чтобы эти проблемы решать опираясь на доверие команды к лидеру.
Именно поэтому тимлид — это почти всегда самый опытный инженер для данного конкретного проекта для данной команды. Или самый ответственный. И редко так бывает, что тимлид обладает специальными знаниями в области управления людьми. Следовательно профессионально решать такие проблемы он не сможет.
Ну… я говорю о роли конечно, а не о человеке. На одном человеке может быть много ролей.
В командах профессионалов (не в какой то технологии, а в принципе) тимлиды обычно просто не нужны. Потому, что люди и сами могут согласовывать решения и работу. В таком случае ресурс лидерства-подчинения, предоставляемый тимлидами, просто перестает быть нужен для менеджеров. Если же команда согласовываться не в состоянии, то из нее выделяют лида.
Но какой то специальной профессии тимлид нет. Человек просто может быть тимлидом в данной конкретной ситуации. А профессия менеджера (который управляет людьми) есть.
Тимлид — это заблуждающийся мидл, у которого наконец-то, что то начало получатся в программировании, и он решил почему то управлять командой, тестированием, дизайном, кадровыми вопросами и т.п, а пм это допускает, в силу своей некомпетентности. Проектами должны управлять специально обученные люди, пм-ы или скрам-мастера.
ПМы ничем не могут управлять потому что они не способны оценить сложность задачи, не способны понять что идёт не так, не способны это исправить и не способны нести ответственность и исправлять ошибки.
ПМы могут помогать тимлиду с кадровыми вопросами (если он сам не тянет) и с идеями по улучшению процесса (если они для этого достаточно компетентны).
Скрам-мастера — вообще люди, которых непонятно кто и зачем придумал. Я ни разу не видел процесса, в котором разработчики правда работают и при этом зачем-то нужен скрам-мастер.
ПМы могут помогать тимлиду с кадровыми вопросами (если он сам не тянет) и с идеями по улучшению процесса (если они для этого достаточно компетентны).
Скрам-мастера — вообще люди, которых непонятно кто и зачем придумал. Я ни разу не видел процесса, в котором разработчики правда работают и при этом зачем-то нужен скрам-мастер.
Если вы что то не видели, это не значит что этого нет. Скрам-мастер входил еще 2017 году в топ самых высокооплачиваемых специалистов в штатах www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha. Для того он и нужен, чтобы заказчик не тратил зря средства, а команда сфокусировалась на результате, и не деградировала и не затачивалась под знания тимлида (который зачастую технически не превосходит, других специалистов в команде), хороший скрам-мастер всегда может объяснить зачем он нужен. Сложность задач не нужно субъективно оценивать ака «тимлидом» (странным мидлом), для этого существует более точные техники типа scrum poker (и совокупное мнение участников команды).
Если за что-то платят — это ещё не значит что оно столько стоит. Любой человек, который умеет себя хорошо продавать получает достаточно много. Если у него при этом ещё и звучное название позиции — то тем более.
И насчёт «может объяснить» — да, именно поэтому мы так много и стоим. Я тоже могу объяснить зачем я нужен и почему кто-то другой не нужен. Люди с хорошими коммуникативными навыками очень хорошо проходят интервью и достаточно много зарабатывают. Это ни о чём не говорит.
А вот если у вас есть статистика о том, что «вот у нас две команды, одна с тимлидом, другая со скрам-мастером, команды одинакового уровня и по таким-то метрикам команда со скрам-мастером выигрывает» — вот тогда тут релаьно есть что обсуждать.
И насчёт «может объяснить» — да, именно поэтому мы так много и стоим. Я тоже могу объяснить зачем я нужен и почему кто-то другой не нужен. Люди с хорошими коммуникативными навыками очень хорошо проходят интервью и достаточно много зарабатывают. Это ни о чём не говорит.
А вот если у вас есть статистика о том, что «вот у нас две команды, одна с тимлидом, другая со скрам-мастером, команды одинакового уровня и по таким-то метрикам команда со скрам-мастером выигрывает» — вот тогда тут релаьно есть что обсуждать.
да статистика такая такая есть..., проекты просто факапятся, потому что тимлиды, становятся таковыми на проекте, просто потому, что они первые попадают на проект, и отбор остальных участников команды, идет уже не выше его компетенции, а так как тимлид держит и админские права на проекте гита или таск менеджера, то там даже овнеры сделать ничего не могут и дальше раскручиваются на деньги, пока не выдерживают и не разгоняют всех. Тимлид — ставит галочку в портфолио, что он «качественно там поработал», а проект затянулся и завалился, потому что команда плохая попалась, причем все специалисты сразу. Вот такая правда жизни. Не надо портить перспективного спеца(мидла или сеньера) и наделять его управленческими функциями.
Это да, если это частный случай, но не может статистика ошибаться по всем скрам мастерам.
Хочется идти в управление проектами, завязывай с программированием (не мешай другим), обучайся методикам эффективного управления (по мне так это еще сложнее чем программировать), и становись проффеcсионалом в своем деле. Но не надо и программировать, и управлять, и тестировать и админить и кадры искать, хотя для домашнего хоумпейжда, можно все это совмещать и быть «тимлидом».
Если за что-то платят — это ещё не значит что оно столько стоит.
Это да, если это частный случай, но не может статистика ошибаться по всем скрам мастерам.
Хочется идти в управление проектами, завязывай с программированием (не мешай другим), обучайся методикам эффективного управления (по мне так это еще сложнее чем программировать), и становись проффеcсионалом в своем деле. Но не надо и программировать, и управлять, и тестировать и админить и кадры искать, хотя для домашнего хоумпейжда, можно все это совмещать и быть «тимлидом».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Должность — тимлид