Должность — тимлид

    Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

    Откуда же появляется разное представление о должности тимлида?


    ПРИМЕЧАНИЕ. Здесь и далее я говорю про тимлида только в рамках команды разработки. Догадываюсь, что многое из рассуждений распространяется и на другие команды, во многих видах деятельности.

    Мне доводилось видеть тимлидов исполняющими роли руководителя проекта, системного аналитика, тестировщика, дизайнера, проектировщика интерфейсов, архитектора, даже специалиста по поддержке пользователей.

    На практике, в здоровых организациях, по моим наблюдениям, роль тимлида обычно занимают разработчики, которые более других чувствуют ответственность за судьбу разрабатываемого продукта, нередко перерастающую в гиперответственность, чем умело пользуется руководство.
    ПРИМЕЧАНИЕ. Гиперответственностью я называю случай, когда человек чувствует себя ответственным за обстоятельства, влиять на которые полномочий не имеет. Я не пытаюсь вложить в это качество ни позитивного ни негативного оттенка, лишь констатирую, что в некоторых сотрудниках гиперответсвенность проявляется.

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

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

    Какая же деятельность для тимлида родная?


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

    Самое простое определение, которое я могу дать для роли тимлида звучит так: «тимлид — интерфейс команды разработки».

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

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

    Что же конкретно тимлид должен делать?

    Он должен суметь сделать так, чтобы каждый член команды справлялся с поставленными перед ним задачами. Для этого нужно, чтобы:
    1. члены команды были согласны выполнять поручения,
    2. достаточно компетентны для этого,
    3. обладали достаточными ресурсами (в первую очередь — временем),
    4. могли ужиться вместе.

    Это и есть фронт работ тимлида.

    Разберем, что с этим нужно делать.

    Лидерство


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

    Тем сильнее лидер, чем большим количеством разных типов сотрудников он может управлять.
    По моим наблюдениям лидерство можно удержать за счет различных факторов:
    1. Проявлять искреннюю личную заинтересованность в успехе проекта. В современной команде разработчиков все видят все, что делают остальные, как делают, насколько стараются. Разработчики с большей охотой пойдут за тем, кто сам вовсю старается ради успеха проекта, даже если этот кто-то и формальной власти то не имеет, из желания помочь. Такой лидер легко удерживает инициативу, пока не выдохнется или не потеряет интерес к проекту.
    2. За счет знания технологий и устройства проекта лучше всех в команде. К таким лидерам тянутся заинтересованные в профессиональном росте разработчики, они часто именно за этим и приходят в проект. Логично, что при достижении разработчиками уровня лидера, если других факторов нет, лидер теряет инициативу, что на практике выражается постоянной критикой решений, порой приводит к игнорированию распоряжений или скрытым саботажам.
    3. Способен добиться уважения окружающих за счет личных качеств. Когда человек объективен, справедлив, последователен, сотрудники могут полагаться на такого человека и его решения. Однако для того, чтобы команда разглядела эти качества в потенциальном лидере требуется время, за которое лидерство захватит кто-нибудь другой. Этот фактор наиболее устойчив к различного рода переменам в команде.
    4. Умение эксплуатировать настроения отдельных членов команды, заставляя действовать по своему плану (кино Filth сразу вспомнилось www.imdb.com/title/tt1450321). Видел таких лидеров, даже немного поработал в профессиональной юности сдуру, но вовремя сбежал. Очевидно, что опытными специалистами, знающими себе цену, долго не поманипулируешь.
    5. Применение административных мер, предоставляемых формальной властью, для того, чтобы заставить сотрудников выполнить обязательства. Если этот фактор лидерства единственный, то это явный пример системы отношений «я — начальник, ты — дурак». Работает также на довольно ограниченном множестве сотрудников.

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

    Компетентность команды


    Достаточно компетентные сотрудники появляются в команде в результате отсева из потока недостаточно компетентных. Помогают в этом тимлиду часто другие сотрудники: наши любимые HR-ы, линейные руководители и проектные, просто неравнодушные сотрудники. Часто тимлид не осознает, как и многие вокруг тот факт, что именно его ответственность в том, чтобы не пропустить в команду некомпетентного сотрудника, то есть того, кто не сможет справиться с планируемыми задачами. Тимлид может полагаться на мнение коллег, руководства, отдела персонала, но ответственность за то, что человека в команду принял — на нем. А есть ли ответственность за то, что не взял в команду компетентного сотрудника? Дело в том, что на практике такую ошибку не проверить, потому, в случае сомнений, кандидату проще отказать, чем многие и пользуются. Кроме того, отклонить кандидата могут и другие инстанции — HR-ы, руководители, в вопросе найма разумно применять право вето.
    ПРИМЕЧАНИЕ. Довольно часто несоответствие ответственности и полномочий проявляется в том, что тимлида не включают в процесс принятия решения о приеме кандидата, или не дают возможности исключить сотрудника из состава команды по инициативе тимлида. Притом ответственность за то, чтобы команда справлялась со своими задачами с тимлида никто не снимает. Вот она — вмененная гиперответственность.

    В чем же здесь проявляется профессионализм тимлида?

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

    Среди способов пополнения кадрами вижу принципиально два подхода:

    1. Брать готовых специалистов с рынка труда.
    2. Воспитывать кадры самостоятельно.

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

    Что же может пойти не так?
    1. Типовая ошибка — найм недостаточно компетентных сотрудников в силу неумения выявить профессиональные качества кандидата. Простые примеры — это неумение или боязнь задать правильные вопросы на собеседовании, смещение акцента на эзотерические особенности технологий, а не на их практическую сторону. Последствия ожидаемы — кандидат не справляется со взятыми командой обязательствами, следовательно и тимлид тоже.
    2. Другая крайность — найм только экспертов. Чтобы не ошибиться в найме после набития шишек, или из желания собрать команду мечты, тимлид тщательно отбирает только не уступающих в знаниях ему самому кандидатов. Так как такая манера больше свойственна лидерам-экспертам, то ценз получается довольно высоким. Кандидаты ищутся долго, затраты на подбор растут, задачи проекта не решаются, а у тимлида есть отличная отговорка — нет специалистов. Но даже когда команда собрана оказывается, что звезды с рутинными задачами готовы мириться, но хотелось бы задач с вызовом (challenge) и каждому, а вот пойти мусор подмести в проекте никому не хочется. Да и обстановка какая-то напряженная становится, как известно у 4-х архитекторов 8 мнений, большинство из них правильные, хоть и противоречат друг-другу.
    3. Еще типичный пример — игнорирование потребности в привлечении в команду сотрудников других специальностей, например фронтендщика, эксперта в определенной БД, проектировщика интерфейса и т.д. Часто такое происходит просто из-за непонимания того, что такой специалист в команде нужен. В итоге команда суровых бэкендщиков разрабатывает кое как работающий фронтенд в своем проекте, команда разработчиков месяцами бьется с оптимизацией PostgreSQL, ну и мой любимый случай — психбольница в руках пациентов.
    4. Пример сложнее — неравномерность найма, взял пачку джуниоров, чтобы два раза не вставать, а они как начали код писать так, что ревьювить команда не успевает, да еще подходят вопросы всякие задают непрерывно, ломают что-то постоянно.
    5. Или наоборот, работаем, концентрируемся на задачах, найм на потом откладываем, как внезапно уходит кто-то из ключевых сотрудников, другой в отпуске/болеет/забрали в другой проект, а на смену никого из подрастающего поколения нет. Скажете, что мол, ситуация неожиданная? Так вот к такой ситуации тимлид всегда должен быть готов, заранее продумывая как он поступит в случае потери того или иного члена команды. А еще лучше если он отношения построит так, чтобы заранее узнать о таком исходе.

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

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

    Оценка работ


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

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

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


    Настроения в команде


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

    Казалось бы, простая задача? Далеко не так! Если между сотрудниками назрел конфликт, то во многих случаях его можно разрешить только исключением кого-то из участников из состава команды. Но на предотвращение конфликта тимлид вполне в силах повлиять, тут универсальных советов не дать, кроме одного: нельзя замалчивать конфликты, при любом инциденте нужно реагировать, как именно реагировать — зависит от конкретных обстоятельств.

    Также тимлиду следует соотносить характеры членов команды, если одного зануду команда переварит, то двух, возможно, уже и нет (ничего не имею против зануд, сам зануда еще тот).

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

    Заключение


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

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

    Интересует мнение разработчиков (в широком смысле — всех, кто работает в составе команд-разработчиков), тимлидов, линейных и проектных руководителей, согласны ли вы с такой декомпозицией роли тимлида? Есть ли у вас какие-либо замечания, дополнения?
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 54

      +2
      Единственное что могу заметить… Что часто когда пытаются внедрить Agile / scrum пытаются сопоставить роли PM, тимлида и т.п. Так вот тимлидов и PM в Scrum НЕТ!!!
        0
        Да, очень часто сталкиваюсь с таким миксом из должностей и ролей. Отсюда же рождение должностей Scrum Master, Product Owner. Причем под Product Owner кого только не поразумевают от системного аналитика до менеджера продукта.
        0
        Не скрамом единым. К тому же он не запрещает назначать другие роли вне каркаса скрама.
        Чем больше ролей — тем больше можно раздать медалек и выделить кого нибудь, чтобы не сбежал. Хехе.
          0
          Может дешевле доску почета передовиков производства завести!?)
            0
            Бывает даже, что дешевле поднять зарплату. Разные бывают механизмы мотивации. Я их не предлагаю, всего лишь говорю о том, что имеет место быть в реальности.
            Перепутать тимлида и пипл менеджера, как сделал автор, это не самое худшее. Нередко позиция тимлида — просто механизм задержать крутого спеца подольше в команде.
        0
        В общем, получается, что тимлид это гораздо больше менеджер, чем программист.
          +2
          Зависит от команды, если команда я, да Вася, то на управление времени не уйдет почти нисколько, но когда команда переваливает за 5 человек на управление уже уходит большая часть времени. А в команды более 10 человек я вообще не верю, они неуправляемы.
            0
            По мне Ваше утверждение так же справедливо как, например, «Программист, получается, больше наборщик текстов». В статье очень хорошо обозначены обязанности тимлида, и объем управленческих работ предлагается приемлемый.
              0
              Ну и странный же вывод. Если бы вы внимательно прочитали статью, то увидели бы — там описано, что основная обязанность тимлида именно управлять командой. А непосредственно программирование — это второстепенно. А управление — это менеджмент. Не знаю, что тут может быть непонятно.
              Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
              И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
                0
                И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.

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

                И если менеджменту уделить процентов 15-20, то это приемлемо. Тимлид все же программист (у команды разработчиков, конечно), и это совсем не ПМ. Не знаю, интересно ли Вам мое собственное мнение, если да, то оно за
                спойлом

                (далее личный опыт исключительно) Все эти управленческие дела при правильном подходе не напрягают… Я и раньше, например, помогал более слабым членам команд в решении проблем, если они в этом нуждались (еще не будучи на позиции тимлида). Добавить к этому распределение задач? Легко, мы используем довольно эффективный метод оценки временных затрат, которому обучены так же и члены команды. Остаются только коммуникации, но с этим вообще проблем не было никогда. Остается только «умение завоевать авторитет» — но это вышло естественным путем, когда не «выпрыгиваешь из штанов» тебя лишняя порция ответственности не напрягает.
                  0
                  Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
                  Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.

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

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

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

                  Ваш личный опыт прочесть было интересно, но я думаю, сколько людей, столько и мнений.
                    0
                    40% времени останется на непосредственно программирование.

                    У меня был опыт работы на проектах и в условиях, где и простому разработчику приходилось тратить по 2-3 часа в день на митинги. Это проблема процессов внутри компании а не конкретных должностей. Вы собственно сами об этом указали. Но если в этих митингах не видно ценности, то может быть имеет смысл поговорить с руководством и как-то оптимизировать процесс? Есть правда еще бюрократия но…
                      0
                      К счастью, я еще не встречал команд, где обычных разработчиков выдергивают каждый день на 3 часа на митинги) Это, должно быть, очень богатые компании, если могут себе такое позволить =)
                      По поводу тимлида, штука вот в чем (из статьи):

                      тимлид — интерфейс команды разработки

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

                        И это правильно, иначе он был бы просто программистом а не руководителем отдела разработки. Есть еще такие персонажи как техлиды, и они обычно кодят больше.
                          0
                          Ну вот. Из этого вывод, что если у тимлида на кодинг остается всего 30% (к примеру) от всего рабочего времени, это никакая не проблема, а просто особенность должности. И к этому надо быть готовым — не каждый программист хочет расти в таком направлении.
                            0
                            Я знаю один интересный прецедент, когда командой python-разработчиков (в рамках весьма крупной компании) руководил PHP разработчик. И там процент времени занятый кодом — 0%. Чисто управление командой, улучшение процесса разработки, собеседования и т.д. И ничего, все хорошо работали, процессы развивались и все такое. По хорошему тимлид вообще кодить не должен, но может. Но по итогу спустя два года (если память не изменяет) ему стало грустно от того что он не кодит.
                              0
                              Было бы очень интересно услышать мнения непосредственных участников. Возможно это случай удачного разделения обязанностей тимлида между несколькими членами команды.
            +3
            > Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
            А мне вот наоборот интересно было бы услышать у кого какие способы сплочения коллектива. Может традиции какие-то, пицца по пятницам?.. Рассказывайте, очень интересно услышать! :)

            По теме:
            Сам я тимлид, свою миссию вижу именно как помочь команде комфортно, профессионально и в сроки выполнять задачи. А так же давать PM'y оценку работ и консультировать по всевозможным техническим вопросам. И да, я пишу много кода, рисую интерфейсы, выдумываю архитектуру и много еще всего, хотелось бы делать этого меньше, но пока никак :)
              +1
              Про тимбилдинг говорить не хотел, так как сам не специалист и не верю в него.
              По крайней мере в тот, который по инициативе администрации организуется.
              Тимлид, кстати, тоже как часть администрации воспринимается, и от его лица тимбилдинги проводить тоже плохая идея.
              Есть тонкий момент в том, что просьба со стороны уважаемого командой тимлида для многих равносильна указанию.
              Но когда речь идет о добровольных мероприятиях тимлиду некоторым отказать сложно, и уже не понять, по доброй ли воле идет сотрудник на мероприятие.

              Хорошая идея взять в команду душу компании, который(ая) будет перехватывать инициативу во внерабочее время, это работает.
              Мероприятия практикуют самые разные, просто пойти в бар, с гитарой на лужайку, в ЧГК сыграть (https://igry-razuma-intellektual.timepad.ru/events/), играют и в покер и настольные игры, катаются на велосипедах.

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

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

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

                Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.

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

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

                Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл :)

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

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

                  На практике же часто бывает так, что на работе у нас каждый сам за себя, причем именно руководство создает такую обстановку, а потом, внезапно, на специальном мероприятии, специально обученные люди (внутренние или внешние), за деньги внушают коллективу, что они — команда.
                  Такой тимбилдинг мне не по душе.
                  Лучше всего, когда инициатива командообразования рождается и поддерживается внутри команды, причем лучше когда это происходит не по инициативе администрации.
                  0
                  В качестве тимлида — главная тема из шуток по сроки «выпустить в продакшен проект самому за две недели, если все пошло в пропасть». А в целом, нужно не знать абсолютно все, а уметь помочь и подсказать в каком направлении «копать» по проекту. Сейчас в планах проводить командные тренинги в неформальной обстановке, когда видишь, что человек не умеет достаточно хорошо пользоваться каким-то инструментом: git, ide, браузерные dev-tools и т.п…
                  И, кстати, да. У нас укрепилась традиция уже на протяжении трех лет — пицца по четвергам.
                    0
                    Пицца по пятницам очень-очень легко вырождается в «Нафиг мы собрались? А, ну да, пиццу поесть и только.»
                    +1
                    Есть ещё одна сторона медали в работе тимлида — обратная связь команде. Без обратной связи люди не понимают, в том ли направлении они движутся. Это правда важно.
                    Когда обратная связь положительная (ну или хотя бы нейтральная), то всё ок. Хотя и тут стоит не перестараться (:
                    А вот когда она отрицательная, это чертовски сложно. Причём в каждой отдельно взятой ситуации сложно по-своему.

                    С тимбилдингами всё не просто. Особенно когда в команде пара интровертов, что в нашей отрасли встречается чуть чаще среднего, и семейные с детьми.
                      0
                      Обратная связь очень важна в работе тимлида, я отношу ее к инструментам поддержания и развития компетенции, а в некоторых случаях и поддержания настроений в команде.
                      Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.
                      +1
                      Очень хорошая статья. Наверное, лучше и не опишешь. К слову про Scrum: возможно кто-то и играет в Scrum без тимлидов, но это создает некоторые проблемы.
                        0
                        Спасибо, всегда можно сделать лучше, было бы время.
                        Мои изучения Scrum'а и допытывания всяких гуру привели меня к выводу, что для Scrum'а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
                          0
                          кто-то играет в скрам без скрам-мастера, в этом проблема, а тимлиды это архаизм, но для небольших проектов годится, немного знает методики управления, немного программирует, способен немного натаскать джунов, но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
                            –1
                            Фундаментальное различие в том, что в скрам-мастер фокусирует команду на результате (скрам — это жестко прописанные роли, правила и артефакты), тогда как тимлид сам распыляется и не может сфокусировать и четко объяснить свою деятельность, не говоря уже о команде (даже в интернете все пытаются по разному формализавать, и изобретать чем же он занимается).
                              0
                              но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать


                              Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают, а то, признаться, я таких за 10+ лет опыта не видел, что-то новое и неоткрытое! :)
                                0
                                О это обширная тема, я наверно буду на пенсии писать про это мемуары, начиная о том как «тимлиды» предлагали писать в коде сервера компоненты для фронтенда, и заканчивая тезисами о монолитной разработке вместо модульной (loosely coupled), плюс всякие пулл реквесты висящие днями на рассмотрении в то время как дедлайн и проект горит. А также как предлагая лучшие практики, получаешь ответы лида типа «у нас это не принято». Или о приватных звонках «тимлидов», с просьбами срочно прекратить разработку и тестирование продукта, вместо того чтобы обсудить все в общем чате со всей командой. И о проектах, которые поднимались из руин за полгода-год, которые факапились около трех лет «опытным тимлидом» с командой разработчиков. Ладно если бы это была случайность и один проект, но это разные проекты, и повсеместно особенно на фрилансе.
                                  0
                                  Тимлид
                                  1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
                                  принимает в разработке активное участие.
                                  2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
                                  (друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
                                  3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
                                  разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
                                  внезапно, может быть несколько активных спринтов, команда не принимает участия в
                                  формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
                                  поддается прогнозированию.
                                  4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
                                  выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
                                  проблемы никого не интересуют.
                                  5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
                                  квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
                                  не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
                                  факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
                                  кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
                                  и тесно взаимосвязано. (tightly coupled).
                                  6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
                                  и затрат времени на это.
                                  7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
                                  кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
                                  8) Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
                                  задачи появляются неожиданно.
                                  9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
                                  без работы.

                                  Знакомые ситуации?
                                    0
                                    Давайте, я отвечу такой аналогией.
                                    У меня есть велосипед — у него отвалилось колесо.
                                    Он был покрашен — краска стала отходить.
                                    Проехав 10 километров, он заскрепел, т.к. не был смазан, а после 20-ти километров появился люфт руля.

                                    Вывод: все велосипеды — зло!

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

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

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

                                      Тимлид держится за место на проекте, но не за сам проект, он скорее завалит проект, чем согласится перейти на скрам, и ликвидировать эту роль.
                                        0
                                        Это ограниченное понимание роли лида, притянутое за уши опыта, через который вы прошли. Повторюсь: не стоит путать свойство функции со свойством исполнителя этой функции. Если, к примеру, вам только и встречались лиды, которые были «дискредитированы» более «сведущими», то это не значит, что все лиды такие :)

                                        Лид не нужен совсем, нет в скраме такой роли.


                                        Если с Скраме нет какой-то вещи, то это не значит, что она не нужна!
                                        Если в Скраме нет роли лида, то это не значит, что никто не исполняет эту роль!
                                          0
                                          Круг замкнулся,

                                          Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают

                                          Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
                                    0
                                    Как говорится почувствуйте разницу

                                    Скрам
                                    1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
                                    четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
                                    менятся как дежурный.
                                    2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
                                    3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
                                    спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
                                    развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
                                    возникновения, а планируются на следующие спринты). При серьезном подходе можно
                                    рассчитать выход продукта и обновлений.
                                    4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
                                    предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
                                    5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
                                    совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
                                    разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
                                    (loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
                                    6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
                                    сущностей. Выявлятся и устраняются причины багов.
                                    7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
                                    находит таск и перечитывает контекст задачи.
                                    8) Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
                                    сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
                                    9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
                                    переход на другой проект или время на обучение.
                                +1
                                Очень понравилась статья, ибо похоже на собственную жизненную ситуацию:
                                я тимлид в аутстафф команде разработки, и как раз-таки являюсь тем самым фронтэндом между руководством (в другом городе, общение скайп+почта) и нашей командой. Распределяю задачи, оцениваю возможности и личностные качества отдельных членов команды, помогаю с вопросами и принятиями решений (помогает бо'льший опыт взаимодейтсвия с дорабатываемой системой). Ну и заинтересованность повыше, конечно… В общем, очень хорошо Ваша концепция ложится на мои реалии, респект!
                                  +1
                                  Спасибо за отзыв, очень важно узнать, что теория попала в конкретный случай!
                                  0
                                  И всё-таки остается загадкой: совершенствование процесса в команде — это основная или побочная обязанность тимлида? С одной стороны, команда сама должна вырабатывать «правила игры», но иногда для этого требуется «волшебный пинок».
                                    0
                                    «Совершенствование процесса в команде» — что вы имеете в виду?
                                    Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
                                    Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
                                    Можно вообразить частный случай для иллюстрации:
                                    Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
                                    Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
                                    Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.

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

                                    В любом успешном проекте есть такой человек, и не обязательно в IT: главный конструктор, ведущий инженер, etc… Если в проекте нет такого человека — это показатель обреченности проекта. Как бы мы ни старались развивать колаборационные навыки, идея и интуиция не масштабируются и не могут функционировать распределенно во многих головах сразу.
                                      0
                                      Статья большая, а все очень просто. Тимлин — это человек способный организовать команду на реализацию заявленного продукта. Все остальное словоблудее. Нужно будет и огород копать пойдет. ))
                                        0
                                        Я с вами не согласен. Возможно попытки формализовать что такое тимлид в разработке обречены на провал. Но то, что вы описали — это пипл менедмент.

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


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

                                        Лидерство — в психологии процесс социального влияния, благодаря которому лидер получает поддержку со стороны других членов сообщества для достижения цели.

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

                                        Конечно часто в компании тимлид может объединять разные роли. Но не надо придумывать новые определения для этого термина сужая его изначальные рамки. Так вы автоматически уходите от реальности.
                                          0
                                          Спасибо за ваше мнение!
                                          Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
                                          Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
                                            0
                                            Я говорю о линейных менеджерах, к которым прикреплены люди. Которым непосредственно репортят. Которые решают проблемы мотивации сотрудников и их развитием в компании. Это не тоже самое, что проектный менеджмент.

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

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

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

                                            Ну… я говорю о роли конечно, а не о человеке. На одном человеке может быть много ролей.

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

                                            Но какой то специальной профессии тимлид нет. Человек просто может быть тимлидом в данной конкретной ситуации. А профессия менеджера (который управляет людьми) есть.
                                          –1
                                          Тимлид — это заблуждающийся мидл, у которого наконец-то, что то начало получатся в программировании, и он решил почему то управлять командой, тестированием, дизайном, кадровыми вопросами и т.п, а пм это допускает, в силу своей некомпетентности. Проектами должны управлять специально обученные люди, пм-ы или скрам-мастера.
                                            0
                                            ПМы ничем не могут управлять потому что они не способны оценить сложность задачи, не способны понять что идёт не так, не способны это исправить и не способны нести ответственность и исправлять ошибки.
                                            ПМы могут помогать тимлиду с кадровыми вопросами (если он сам не тянет) и с идеями по улучшению процесса (если они для этого достаточно компетентны).
                                            Скрам-мастера — вообще люди, которых непонятно кто и зачем придумал. Я ни разу не видел процесса, в котором разработчики правда работают и при этом зачем-то нужен скрам-мастер.
                                              0
                                              Если вы что то не видели, это не значит что этого нет. Скрам-мастер входил еще 2017 году в топ самых высокооплачиваемых специалистов в штатах www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha. Для того он и нужен, чтобы заказчик не тратил зря средства, а команда сфокусировалась на результате, и не деградировала и не затачивалась под знания тимлида (который зачастую технически не превосходит, других специалистов в команде), хороший скрам-мастер всегда может объяснить зачем он нужен. Сложность задач не нужно субъективно оценивать ака «тимлидом» (странным мидлом), для этого существует более точные техники типа scrum poker (и совокупное мнение участников команды).
                                                0
                                                Если за что-то платят — это ещё не значит что оно столько стоит. Любой человек, который умеет себя хорошо продавать получает достаточно много. Если у него при этом ещё и звучное название позиции — то тем более.
                                                И насчёт «может объяснить» — да, именно поэтому мы так много и стоим. Я тоже могу объяснить зачем я нужен и почему кто-то другой не нужен. Люди с хорошими коммуникативными навыками очень хорошо проходят интервью и достаточно много зарабатывают. Это ни о чём не говорит.
                                                А вот если у вас есть статистика о том, что «вот у нас две команды, одна с тимлидом, другая со скрам-мастером, команды одинакового уровня и по таким-то метрикам команда со скрам-мастером выигрывает» — вот тогда тут релаьно есть что обсуждать.
                                                  0
                                                  да статистика такая такая есть..., проекты просто факапятся, потому что тимлиды, становятся таковыми на проекте, просто потому, что они первые попадают на проект, и отбор остальных участников команды, идет уже не выше его компетенции, а так как тимлид держит и админские права на проекте гита или таск менеджера, то там даже овнеры сделать ничего не могут и дальше раскручиваются на деньги, пока не выдерживают и не разгоняют всех. Тимлид — ставит галочку в портфолио, что он «качественно там поработал», а проект затянулся и завалился, потому что команда плохая попалась, причем все специалисты сразу. Вот такая правда жизни. Не надо портить перспективного спеца(мидла или сеньера) и наделять его управленческими функциями.

                                                  Если за что-то платят — это ещё не значит что оно столько стоит.

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

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

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