Комментарии 13
Я только начинаю свой путь в качестве тимлида (который по факту ещё и техлид) , было очень полезно почитать про ваш опыт. Спасибо.
Интересна статистика, сколько в среднем вы тратите в неделю на каждый из 4х пунктов и считаете ли вы такое распределение оптимальным.
Я время делю на внутренние дела (командные) и внешние (общение с бизнесом и т.д.), а оба типа этих дел есть в каждом пункте, поэтому сложно сказать, сколько времени уделяется на каждый пункт. По календарю у меня получается такая схема: 16 часов на команду и 24 часа в неделю на "внешние" вопросы (согласования с бизнесом и т.д.). Но не всегда все 24 часа в неделю заняты внешним общением, тогда я просто беру и делаю внутренние задачи. Я бы не советовал выделять конкретное время под каждый пункт, по крайней мере, у меня это не работает. Просто выделяйте слоты, и, когда есть свободное время, выполняйте накопившиеся дела.
В общем, спаси Господи от тимлидства :) Мне кажется психику ломает знатно.
ИМХО - роль тимлида часто путают с ролью менеджера проекта.
а последний ниже тимлида?
Ох, это очень коварный вопрос. И, вопрос провокационный! Я, пожалуй, на него отвечу. Но, боюсь, большинству читателей мой ответ сильно не понравится. Поэтому сразу оговорюсь - всё нижеизложенное является моим личным мнением и на истину в последней инстанции я не претендую. Просьба к@кашками сильно не кидаться :)
Для начала, давайте разберемся, кто за что отвечает.
В моём понимании ПМ отвечает за коммуникационный и организационный успех проекта. В первую очередь ПМ должен наладить эффективную коммуникацию с бизнесом, добиться (с помощью аналитика) корректной формализации поставленной задачи и договориться с бизнесом о прозрачных критериях оценки предстоящей работы. Во вторую очередь менеджер должен запустить процесс разработки, делегировав полномочия соответствующим техническим специалистам. В третью, производить контроль процесса разработки в соответствии с критериями из первого пункта. В четвертых, наладить обратную связь с бизнесом, чтобы своевременно корректировать цели проекта и критерии успеха.
Тимлид, в моем понимании, это как раз тот самый технический специалист, которому ПМ делегировал полномочия по принятию технических решений. Задача тимлида - обеспечить технический успех проекта. Чем должен обладать тимлид, чтобы добиться технического успеха? В первую очередь соответствующими техническим компетенциями. Нужны как знания так и опыт разработки, чтобы принимать взвешенные технические решения. С одной стороны заложить достаточную гибкость и устойчивость в фундамент проекта, с другой не скатиться в оверинженеринг. С одной стороны держать руку на пульсе индустрии разработки, чтобы подобрать актуальный и надежный технический стек, с другой, не поддаваться хайпу, и не тащить в проект все новомодные фреймворки и технологии. Тут нужны глубокие технические знания и психологическая зрелость, чтобы балансировать на лезвии ножа. С одной стороны у тебя унылое легаси а с другой ад из фреймворков. А посередине - остриё ножа, которое в кровь режет ступни тимлида.
Во вторую очередь, нужно четко понимать, что тимлид в одиночку физически не может решить все задачи, которые перед ним ставит бизнес. Поэтому тимлид должен сформировать команду инженеров единомышленников для решения поставленной задачи. Тут нужны развитые лидерские качества, чтобы завоевать симпатии и уважение инженеров, с которыми ему предстоит добиться успеха. (Поэтому ИМХО - тимлмид, который не кодит - это не тимлид. Во первых он не приобретает новые технические навыки и опыт, во вторых быстро теряет технологический контекст проекта. Ну и в третьих, сложно завоевать симпатии и уважение инженеров, если ты отсиживаешься в теплом блиндаже, пока они барахтаются в окопах).
Поэтому ответ на ваш вопрос такой - в некотором идеальном сферическом проекте некоторый идеальный сферический ПМ должен стоять НАД некоторым идеальным сферическим тимлидом.
Но, жизнь штука сложная, и ничего идеального и абсолютно сферического в ней не бывает. Что может пойти не так?
Ну, во первых, хороший менеджер в наших широтах это редкий зверь, достойный занесения в красную книгу. Среднестатистический российский менеджер не умеет делегировать и коммуницировать. Он умеет только командовать. Главная задача, в его понимании, быть тут самым главным начальником. А решения (опять таки в его понимании) может принимать ТОЛЬКО начальник а не всякая инженерная шушера. Поэтому он, вместо делегирования полномочий принятия решений техническому специалисту, лезет во все решения сам, даже когда ничего в технической части не понимает. На всякие писульки от аналитика он тоже не особо обращает внимания, ведь это он тут начальник, и нечего тут всяким там непонятным аналитикам ему что то указывать. Коммуникационные цепочки он тоже не желает выстраивать, потому что это отнимает слишком много времени и сил, которые ему требуются на принятие вообще всех решений на проекте. Поэтому коммуникационные вопросы он старательно перекладывает на плечи инженера - чтобы не возиться со всякой мелочевкой вместо принятия важных решений. Вследствие такой политики разработка неизбежно начинает хромать. Решение у этой проблемы может быть только одно - найти и выпороть виноватых! Как следствие - токсичная атмосфера в команде, нежелание людей брать на себя ответственность и деградация командной работы - каждый сам за себя!
Во вторых хорошие тимлиды в наше время тоже начали вымирать. В индустрию хлынули толпы вайтишников за баблом. Копаться во всей этой технической баламути им не очень хочется, да и как то там все непонятно. Поэтому лучше стать начальником, чтобы командовать. А как им стать? В ПМ'ы сходу пролезть сложно, так как они сами те еще начальники. Поэтому самый простой путь - растолкать локтями этих ботанов-инженером и стать типа тимлидом. Чтобы не копаться во всей этой технической хрени, а просто проводить дейлики и двигать задачки в борде. Огребать от ПМ'а такому лиду тоже не очень хочется, поэтому в случае любых проблем он быстро находит рядового виноватого, чтобы ПМ его выпорол.
Ну а бизнесу что остается? Только смотреть на всю эту вакханалию круглыми глазами и тушить пожар баблом. В результате проекты кое как вызревают, но в них приходится вливать неадекватно много времени и денег, получая на выходе весьма сомнительное качество.
Поэтому в суровой реальности лучше поставить ПМ'а и тимлида на одном уровне. Если это хороший ПМ и хороший тимлид - то они быстро сами между собой договорятся о зонах ответственности, и запустят разработку. Если у вас хороший ПМ и хреновые тимлид, то хороший ПМ, за счет развитых софт скиллов, быстро найдет хорошего инженера в команде, и сделает из него "теневого" лида, и потихоньку выжмет официального тимлида на какую нибудь левую менеджерскую должность. Если у вас хреновый ПМ и хороший тимлид, то хороший тимлид сумеет изолировать ПМ'а от процесса разработки, взяв, по сути, обязанности ПМ'а на себя. Ну а если у вас одновременно хреновый ПМ и хреновый тимлид - то наверное стоит задуматься, что вы делаете не так :)
Спасибо за подробный ответ. Тогда тимлид = техлид. А, вообще, я сторонник советного управления, когда нет лидера, точнее их, например, 4 - север, юг, запад, восток :)
Хорошая статья. Довольно детально прописано чем тамлид занимается, или должен заниматься. Немного перебарщиваете с принятием решений, но в пределах нормы. Да как ниже отмечено тимлид действительно близок к техлиду иначе лидерство не захватить. Однако как раз из-за отмеченных выше персональных особенностей техлид, или технический директор, не обязательно самый продвинутый по теме, но зато имеет доминантную составляющую в характере. Да, для дилетанской, то-есть основанной на собственном опыте, оценки персональных характеристик можно использовать популярную модель DISC.
Все сводится к тому, что теперь твой результат - это результат всей твоей команды. Если мыслить в такой парадигме, то задачи легко находятся)
Спасибо за интересную статью!
Вроде бы большая часть упомянутых вещей на поверхности, однако, (во всяком случае у меня, начинающего в этом качетсве сотрудника) формируется стойкое ощущение, что если не читать вот такие материалы, то ясность и понимание приходит только с годами и только через боль.
А я ненавижу писать код. Но по образованию программист.
Чем заняться тимлиду, если не кодить? Рассказываю о своих задачах