Комментарии 19
Спасибо, отличная живая статья.
У меня вопрос: какая на твой взгляд самая неприятная часть работа техлида? Ну если такая есть)
>По факту ребятам нужно было время, чтобы вникнуть в задачу и понять, как её реализовать, а потом уже разрабатывать.
Но, как обычно, на планировании все видят задачу первый раз, в постановке никто не разбирался, поэтому метают кости играя в "покер"?
Они просто играли в неправильный покер, о чём автор позже и говорит.
Когда у нас в одной из команд был подобный покер, кто называл меньшую оценку тот задачу и забирал. На то он и покер, ставки должны играть. Иначе зачем это называть покером?
Мне из статьи больше идея фича-лида понравилась. Один человек должен прорабатывать требования к фиче, нарезать задачи и принимать MR'ы. Когда во всей команде занимается этим один человек (тим-лид), то на него приходится очень большая нагрузка. Когда фичей никто выделенно не занимается, тогда и планирование превращается в лотерею, и "чужие" MR воспринимаются просто как внешний раздражающий фактор. Да и код-ревью задачи, в которую ты не погружён, вырождается в "скобочки не так расставил".
Тут больше не про постановку задачи, а про опыт работы с той или иной технологией или знание самого сервиса. Что-т оя знал лучше и поэтому мог решить вопрос за 2 дня, а кто не знает что это - он и гвоорил что 5 дней... и очевидно, чт оесли заадча упадет не мне , то и решение будет больше чем у меня.
По постановке задачи - мы предварительно задачи смотрим до оценки и накидываем вопросы, что нам непонятно и на планирвоание уже приходим более подготовленные. Но от покера в итоге все равно отказались.
Сквозь всю статью прослеживается, что вы автор путаете тех лида и тим лида и перескакиваете с одного на другое, будто это одно и то же. Следовательно статья не соответствует заголовку.
Запомните раз и навсегда - тех лид и тим лид это две разные роли:
Тех лид отвечает за технические решения / кругозор / менторство, но никогда не занимается развитием команды, решение межличностных конфликтов, разговоры 1-на-1 и тому подобное. Тех лид в первую очередь читает техническую литературу
Тим лид, напротив - ему абсолютно все равно, что там происходит в технической части. Его задача развивать и подбирать команду для наибольшей эффективности, решать личные конфликты, быть более дипломатичным, проводить ревью 1-на-1. Тим лид в первую очередь читает литературу по психологии
При этом есть компании, в которых выделяют эти роли, а есть такие, где мешают в одного человека. Но по правде сказать это хрень. Такой человек не будет делать хорошо ни то, ни другое, у него не хватит времени и/или когнитивная нагрузка будет слишком высока. Пока такой человек проводит собесы или решает конфликты как тим-лид, в то же самое время он теряет техническую экспертизу и наоборот.
Ну не знаю... Когда у тебя два миддла на код ревью поругались, это вот чья задача выбрать верное решение? Техлида. И как его донести, не касаясь вот этого всего софтового? Если у тебя в роли есть "лид" - то все, здравствуйте вопросы управления людьми.
Не уверен, что всегда тех лид...
В любом случай путь эскалации примерно такой: сами > обратиться к техническому авторитету (тех-лид / сениор) > обратиться к дипломату-психологу (тим-лид / начальник отдела).
Если это был локальный конфликт за табы/пробелы, то решат сами или с авторитетом, а если это было триггером в затянувшемся скрытом конфликте (один из них не моется и воняет) - тех лид тут не разрулит. Там может и растаскивать придется путем перевода в другую команду / отдел или увольнением.
Оу, холивар напрашивается 🤩
Я согласен, что тимлид - больше отвечает за процессы, а техлид за техническую часть, но ничего не мешает немного мешать эти роли и каждой роли что-то заимствовать от другой роли.
Теперь встречные вопросы к вышеуказанным аргументам:
Почему техлид не может решать межличностный конфликт, если он непосредственный участник его? Кажется если это лид, он должен обладать достаточными софтовыми навыками чтоб разруливать такие вопросы, как холивар про табы и пробелы :) Это должно быть одной из его обязанностей в принципе, раз он уже лид.
Почему техлид не может проводить 1-1? На мой взгляд это одна из форм передачи своих навыков коллегам. Например на 1-1 подсветил зоны роста для следующего грейда, выявил потребность коллег, затем собрал всю команду и сделал презентацию, рассказал про технологию/паттерны и тд. Почему нет?
Как тимлид будет развивать команду, если он "психолог", а не технарь? В таком случае он сможет только софты прокачивать, а не харды подтягивать, а это уже однобокое развитие (если так можно выразиться)
Ну не может тимлид забивать на техническую часть, ведь к нему в любом случае будут приходить с вопросами - "не работает сервис", "а тут бага" и т.п. И соответвенно, если таких вопросов много, значит с технической частью что-то не так и надо ее подтягивать, а у него нет компетенций - и что делать? Если честно, я бы такого тимлида, который забивает на техническую часть, уволил бы 😅
Правильно написали, что в разных компаниях все по разному, у каждой компании свои этапы развития и свои процессы, поэтому это и нормально 😎
Пока такой человек проводит собесы или решает конфликты как тим-лид, в то же самое время он теряет техническую экспертизу и наоборот.
Вот тут не понял, разве можно потерять навык, если ты проводишь собесы? Тем более на собесах и софтовые вопросы задаются и технические. И кажется техническую экспертизу сложно потерять, если только не кодить полгода и т.п. Да и чем выше грейд, тем менее кодинга получается (лид, архитектор, лид юнита и тп) - это же очевидно, и при этом их не называют же тимлидами...
Думаю ответ на все один - обязанности и ответственность каждой роли и распределение ролей между людьми.
Я сюда пришел почитать добротную статью про тех лида (было уже 30 плюсов), а что я вижу в первых абзацах? Кривое распределение обязанностей и ответственности.
Продакт отвечал за поставку и описание фич, за развитие софтов команды
Продакт как роль не должен отвечать за развитие софтов команды. Его задачи (здесь и далее в том числе, конечно же, ответственность за принятые решения) - мониторить рынок, аудиторию/потребителей, конкурентов, цены, разрабатывать гипотезы и обкатывать их с использованием каких-нибудь там тестов (типа A/B), разрабатывать схему приоритезации фич (по охвату, по потенциальном доходу и т.п.), расставлять в итоге приоритеты, готовить материалы для продажников, анализировать источники новых идей (как минимум их два - это запросы на новые фичи и саппорт (баги) от текущих клиентов) и тому подобное.
При таком обширном наборе обязанностей - если человек с ролью "продукт" действительно ответственно относится к своим обязанностям, ментально глубоко погружается в свои задачи, чтобы сделать их качественно - у него не останется когнитивных и/или временных ресурсов делать что-то еще.
Мало того, крайне желательно оставлять человеку с любой ролью пространство, чтобы у него не создавалось впечатление бесконечной работы, чтобы это в итоге не привело к выгоранию.
Идем дальше
за развитие софтов команды
Это чисто работа тим-лида. Теперь вопрос, получается ваш руководитель (как человек) взял на себя роль продукта и роль тим-лида. Тогда почему вы себя называете тим-лидом? У вас что два тим-лида? Как предполагается это будет работать? Если вы все же на самом деле не тим-лид, то может быть тогда уберете из статьи слово "тим-лид", и она наконец станет соответствовать заголовку?
Дальше
мне выделили ... развитие технических скиллов команды
Можете мне не верить, но это тоже задача и ответственность тим-лида. Только исполнять ее будет не он или не только он. Задача тим-лида в этом случае организовать развитие технических скиллов команды. Как? Ну например выбить бюджет на обучение, огласить условия всей команде, рекомендовать тем или иным сотрудникам пройти те или иные курсы (на основе фидбека, собесов 1-на-1 и других источников). Или например попросить тех-лида (или сениора за отсутствием) раз в месяц делать презентации о том, какие технические челленджи были и как победили.
То есть реально, у вас в команде два тим-лида. Вы назначили роли к людям как многие-ко-многим.
мне выделили техническое оснащение продуктов (архитектура, стабильность, сопровождение, оптимизация работы сервисов)
Тут наконец добрались до обязанностей тех-лида в той или иной мере.
Теперь по вашему коменту
Почему техлид не может решать межличностный конфликт, если он непосредственный участник его?
Может, в какой-то мере и будет, раз его касается, но, с другой стороны, а почему тех-лид не может попросить совета у более разбирающегося в психологии человека?
Почему техлид не может проводить 1-1
Это не его обязанность как роли. На собесе 1-на-1 нужно учитывать психологические особенности конкретного сотрудника. Обработать его запросы (на повышение зп) и возражения. Это психология. Прежде чем это делать - нужно обладать определенным качествами и/или почитать книжки по психологии и переговорам. Просто походу далеко не все это осознают и делают как придется, у кого-то получается. Это реально тонкая грань. Можно повысить зп человеку так, что он уволится в скором времени после этого.
А вот тим-лид обязан это делать. А до этого он еще должен собрать фидбек по сотруднику (путем опроса например), и если развивать эту идею - то в целом организовать систему грейдов и сбора фидбека.
Как тимлид будет развивать команду, если он "психолог", а не технарь?
Чуть выше привел пример с организацией обучения и делегированием некоторой части.
Ну не может тимлид забивать на техническую часть, ведь к нему в любом случае будут приходить с вопросами - "не работает сервис", "а тут бага"
Как раз таки нет, к нему не должны ходить с такими вопросами, у него куча других забот. Это к тех-лиду.
Вот тут не понял, разве можно потерять навык, если ты проводишь собесы?
Да, потому что сениор, который один раз провел собес, а все остальное время тушит прод - это не тим-лид. Это сениор, который один раз провел собес.
У тим-лида, по аналогии с продуктом (см выше) тоже много обязанностей и по хорошему они займут 80% его рабочего дня, каждый день. И если человек взял на себя одновременно обе роли и при этом у него горит прод - он не сможет успеть и там и там. Очевидно, что здесь и сейчас он пойдет чинить сломанный прод (он не потерпит) и так каждый раз, а сотрудник-человек может и потерпеть, а что потом? Кто и когда будет "чинить" "сломанного" сотрудника?
Да, и тех-лид тоже ходит к тим-лиду на 1-на-1, ведь он такой же сотрудник, как и все остальные и хочет побольше зп.
Прям заинтриговали своими рассуждениями... 🤔
А можете привести пример как должна выглядеть команда по вашему мнению, прям интересно узнать ваш опыт и видение.
И еще такое ощущение складывается, что на 1-1 просят только повышение ЗП... Хотя 1-1 процеес регулярный и должен проходить с какой-то периодичностью (ежемесячно - ежеквартально). Я был бы в шоке от коллег, если бы на каждом 1-1 у меня (или у тимлида) просили повышение ЗП.
И.... я кажется понял, что вас тригернуло... что я говорю про техлида, затем пишу что "всегда хотел стать тимлидом", но при этом меня позвали стать техлидом. И дальше собственно вроде везде стараюсь использовать слово техлид.
Я не тим-лид, обширного опыта построения команд у меня нет, просто приходилось участвовать постольку-поскольку.
Давным-давно я официально был тех лидом пару лет и немного совмещал с тим-лидерством (не официально). Мне просто повезло с командой. И тогда же, в связи с некоторыми событиями пришлось осознать, что это две разные роли: компании, которые предлагали вакансий чистых тим-лидеров и собеседования - там совершенно другие вопросы, почти никакой техники, зато куча вопросов "а что бы вы сделали в такой ситуации {описание конфликта интересов в команде и/или с вышестоящим руководством}", на которые я не мог достойно ответить. Но таких компаний на самом деле меньшинство.
Есть 5+ летний опыт ведения продуктов, сначала в одиночку (не считая CTO), а затем в две команды со скрам мастером, продукт овнером (причем он пришел позже меня), на данный момент уже пятью программистами и 2-3 тестировщиками и недостатком ресурсов при этом (все у нас очень плотно, работы больше чем людей).
И я все еще не тим-лид и даже официально не тех-лид, просто ведущий разработчик, чтобы это не значило.
Из-за недостатка ресурсов - сразу видны проблемы с некорректным распределением обязанностей. Даже если бы у меня было желание именно тим-лидить, у меня тупо не было бы на это времени.
По моему мнению структура должна быть следующей:
Роль, которая управляет (лидит) людьми. Неважно как ее назовут (тим-лид или начальник отдела по старинке). Он нанимает, увольняет (кстати у тим-лидов зачастую таких щедростей нет, а значит и меньше рычагов влияния), он проводит 1-на-1, отслеживает настроения, думает как уладить конфликты, думает про мотивацию, обучение, выгорание, и все такое. У нас это CTO.
Роль, которая управляет (лидит) продуктом - это тот самый продукт овнер, выше я описывал то, чем он примерно должен заниматься, и я, до недавних пор, подобным занимался с продукт овнером на пару, но больше из-за того, что я был раньше. Сейчас с меня сняли эту когнитивную нагрузку
Роль которая управляет техническими решениями - опять же, не важно какое название (главный программист, тех-лид, архитектор). В начале это может быть один человек-оркестр (архитектор-программист-тестировщик). И у меня на этой позиции много работы - подумать как мы будем делать то, что хочет продукт-овнер, мониторить и тушить прод, разруливать выполнение крос-командных задач (всех пинать, чтобы задачи делались), оптимизировать, кодить непосредственно фичи, вытаскивать общие вещи на уровень компании, чтобы переиспользовать в других продуктах компании, придумывать как мы будем делать кросс-функционал типа сквозного логирования бизнес потоков через все продукты (у нас они связаны, там как-бы эко система и события перетекают из одного в другой). Ну и по мере развития продукта это потом можно разложить на отдельные роли и людей и появится команда аналитиков-программистов-тестировщиков. Что же касается взаимодействия с людьми - я могу пару-тройку раз сказать человеку что не так, но вряд ли это будет звучать мягко и дипломатично, и если ничего не меняется - я сообщаю 1-ой роли о проблемах
И главное - нужно разделить эти роли по разным людям. В целом совместить можно, но ничего хорошего не выйдет.
Я в какой-то момент (когда стартовал новый продукт) совмещал 2-ую и 3-тью роли. Когда клиентов пара-тройка - это возможно, когда их уже пара десятков, то слишком много времени уходит на саппорт, нет времени кодить фичи и там уже надо начинать строить отдел тех поддержки.
Что касается 1-на-1 - по моему, если отбросить всю мишуру, задача минимум чтоб не уволили, задача максимум чтоб повысили зп. У нас эти созвоны раньше были каждые полгода, сейчас кажется перешли на годовые. Так же у нас есть опросники, C-level опрашивают что хорошего/плохого скажешь о компании и что хорошего/плохого скажешь о {фио сотрудника}.
Плюс вайб, редко встретишь того, кто обдумал все эти роли.
Очень часто смешиваются либо все три, либо две.
И иногда появляется четвертая под название проджект менеджер, который часто является симптомом, что совершенно похерили процесс(но не всегда, есть заказная разработка, где на нем операционные процессы взаимодействия с заказчиком могут/должны быть)
Интересно, вашу оценку услышать, тому как я это долго в себе собирал
Обычно должно существовать две иерархии, что не всегда в реальности сущесвует.
Продуктовая - Продукт овнеры и вверх до CPO
Техническая - Тим Лиды и вверх до СТО, тех лиды могут быть как выделенное должностью небольших групп и держать ответственность за определенные сервисы(например, группа отвечающая за стабильность базовой технологии), так как и назначаемой в рамках квартального планирования ролью, с постоянно меняющимся составом группы и сервисов в ответственности(например, группы развития новых продуктов)
Тим лид - отвечает за некое количество людей и сервисов, отвечает за длительное удержание людей в отделе, отвечает за дополнительную решение/эскалацию факапов смежников, которые не может повлиять тех лид(приносит проблемы тех лид), в моем мире по этой иерархии еще согласуется задачи полугодия вместе с руклем тим лида(руклем службы/отдела) и продактами, задач этого квартала полугодия, потому что тим лид отвечает за надежность сервисов в своей отвественности своих тех лидов и разрабов и развитие базовых технологий команды, но должен учитывать проблемы тех лидов и выбивать какое-то время на реализацию тех проектов в полугодии вместе с задачами приносимыми продактами. Мне больше нравится когда тим лиды по определенным направлениям, фронтенд, бекенд, тесты ..., но кросс варианты в целом тоже возможны. Также задача лида вовремя контролировать зоны отвественности своих разрабов и тех лидов, чтобы вовремя их разгружать и держать пакет проектов более менее, актуальным. Развитие людей включая их на разные проекты по их желаниям и потребностям, работа с выгоранием, назначение на роли тех лидов ...
Тех лид - Хороший инженер отвечающий за сервис или крупные проекты квартала/полугодия, его выбирают лиды выдавшие своих разрабов на проект, но как правило не так дико много людей хотят на эту роль, поэтому все желающие просто делят проекты между собой после квартального планирования. (Кто-то долго отвечает за одно, другие меняют проекты под продуктовые цели). Его роль техническая проработка проекта, договор с продуктом или стейкхолдерами по объему, срез углов, эскалирование факапов смежников и угроз срокам, решение конфликтов если случается с текущей группой, эскалирование в лидов направлений, у меня, например, в такой группе было 2 выгоревших фронт от разных тимлидов, поговорили, передали в лидов дальше их работа. Надежность, проход qa, тех метрики, вывод в прод. Анализ людей и выдача задач по их навыкам или желательно на грани возможностей для развития.
Продук овнер - анализ рынка, ответ на вопросы тех лида или команды по согласованным и взятым в проработку/работу проектам, согласование объема работ и реальных сроков на проекты, эскалация в своих руклей и тим лида, если кажется что тех лид задерживает или дает нереальные сроки, для доп кросс ответсвенности. Ну и кучу на самом деле продуктовой работы, взаимодействие с дизайнерами, аналитиками, продажа идей CPO и руклям отделов ...
Иногда появляется проджект менеджер, это часто происходит при отсутствие нормальной тех вертекали и по факту это менеджер с ролью тех лида(знаю в альфа банке была роль технический менеджер проектов, на других проектах видел аналогичную роль, как правило символ того, что у Тим лида и рукля отдела нет права отказаться и их хотят контролировать на предмет, что вот они помнят вообще все хотелки и сделаю все в х10 от возможностей команды или опять же что они не обманывают по срокам продуктовую вертикаль)
Но есть виды разработки, где есть всякие договора, учет человеческого времени предоставляемых заказчику, взаимодействие с закупками и еще куча вещей, которых я честно сказать сильно не знаю, то тут он вполне на своей роли
Очень долго этот коммент конечно модерировали, сутки почти
Дополню
И интересно, что часто смешивается роль тех лида и продакта, просто кого-то на проекте нет, что вызывает у человека совмещающего роль конфликт интересов с самим собой и шизу, потому что цель одного выводить как можно быстрее нужные ему фичи и максимального объема, а цель второго выдать реальный объем, который может потянуть команда и не дать им выгореть, плюс дать такой объем работы, который принесет максимально пользу менеджеру и решит его проблемы
Еще тех лиды в целом могут вести группу проектов в некий интервал времени, поэтому у него могут быть части роли тим лида по назначению еще меньших групп с их фича лидами/лицами принимающими решения по конкретным под проектам(иногда может быть сеньор, который просто берет на семя один из проектов тех лида, тут конечно вопрос нужен ли ему тех лид или он может быть как IC(Individual contributor) в этом полугодии, ну в целом он может быть приданный к крупному проекты для усиления тех лида)
Плюс, все что выше написал, как обычно лишь субъективное мнение участника процесса с разных сторон, потому что врят ли тут есть объективный ответ и часто нужно подстраивать детали вышенаписанного под реалии конкретной компании/бизнеса и его целей и возможностей
Плюс само взаимодействие если его жестко не регламентировали и мы не ждем ответ от коллега по таймеру и прочие ужасы корпоративного ада, имеют место ломаться, там не услышали, там кого-то не позвали, там мы думали другой ответственный, так что часто кому-то смежную роль все равно приходится страховать, но это выбросы, а не основа идеи
Действительно интересная статья. С удовольствием прочитал утром перед работой, испытывая сейчас чувство самозванца)
On a side note, было бы интересно подробнее послушать про кейс с видеозвонками: в чем была проблема, как решили и тд.
Разработчик и руководитель это не только разные типы темперамента (интроверт vs экстраверт), это в принципе разные виды деятельности, методологически отличаются не меньше, чем писатель и продавец, пилот самолета и машинист тепловоза и т.п.
Программист же тоже не универсальное понятие - таланливый бэкендер может быть абсолютно безнадежным фронтендером и наоборот. Выдающийся Java-ист будет скорее всего будет бездарным C++ ником и т.д.
Плюс извечный спор собор vs базар - или набрать/воспитать однотипных середнячков, и они будут пилить выдержанный в стилях и подходах монолитный продукт по утвержденному шаблону, или набрать ярких, выдающихся индивидуалов, абсолютно несовместимых между собой в командной разработке, которые будут строить зоопарк из микросервисов из всех модных и уже не модных очередных и проходящих через год-два заблуждений.
Вариаций несоответствия и несовместимостей типов личности можно привести массу. Талант же руководителя в том и заключается, чтобы обеспечить максимальную отдачу от отдельно взятого сотрудника, поставить его на то направление, на котором он будет наиболее эффективен и продуктивен. Попытка же построить команду на принципе "просто делай как я, тиражируй успех" - в подавляющем числе случаев обречена на провал и фиаско, это типичная ошибка молодого руководителя, особенно из бывших инженеров.
На именно руководителей вообще отдельно учат: MBA, ОРУ, PMBOK и прочие моменты, и изначально прокачанное инженерное мышление там скорее вредит, чем помогает: из хорошего футболиста не сделать ни пловца, ни теннисиста. Да и тренер из него тоже будет скорее всего так себе, за очень редкими исключениями, и уже после 40-ка лет. Тренер 25 летний - это нонсенс даже в футболе.
От технаря к техлиду: битва с самозванцем