Comments 12
Спасибо за пример организации работы вашей команды, даже если подход не совпадает с читательским, узнать другую логику всегда интересно.
Но есть пара вопросов, не затронутых или слабо затронутых по тексту:
компания небольшая (80 чел.), среди них и бухгалтерия и прочие, то есть сама техническая команда (с учётом что команд тоже явно несколько) - наверняка буквально несколько человек. Зачем для такого небольшого числа отдельный менеджер, частично покрывающий задачи тимлида? Распределять задачи с учётом нагрузки в такой небольшой команде может и сам тимлид, и он как один человек очевидно будет больше в курсе кто как что "тянет" чем менеджер.
вы приводите пример плюса в том, что менеджер и тимлид с учётом разделения задач могут вести параллельно несколько проектов. Вы сами используете такой подход?
есть очень некрасивый приём из жёлтой журналистики: подзаголовок "Кто проводит код-ревью" и нет ответа в тексте, вместо этого идёт ссылка на другую статью. Можно было бы дать ответ, а потом написать "подробнее процесс код-ревью рассмотрен там-то".
Здравствуйте! Отвечаю на вопросы:
1. На самом деле, у нас довольно большая техническая команда — больше 50 технических специалистов (разработчики, DevOps, QA), в двух крупных юнитах больше чем по 20 разработчиков. Команды в частности тоже могут быть крупными: на некоторых проектах в пике может быть задействовано до 30 человек (это вместе с менеджментом, дизайном, аналитикой и пр.) В общем, менеджеры действительно нам нужны и они очень спасают. Возможно, это еще и следствие специфики заказной разработки, где очень много коммуникации с заказчиком, интеграций и пр. — менеджер значительно снижает нагрузку на тимлида. Так же и задач на проекте в день может возникать десятки. Если требования поступают через тимлида, то завести задачу самостоятельно даже эффективнее. Например, если что-то супер срочное и важное, то быстрее завести самому и затем оповестить менеджера о новых планах. Но большая часть времени работы следуют плану, поэтому удобно, когда за ним следит менеджер. Конечно, в любой момент можно пригласить тимлида и консультироваться с ним. При этом, существуют дейли, общие планирования, проектирования и другие встречи, благодаря которым тимлид остается в контексте.
2. Да, по своему примеру могу сказать, что некоторые лиды ведут по несколько проектов. Я в течение последнего года вел два проекта с абсолютно разными контекстами. В целом, получалось довольно эффективно. Большую часть времени удается уделять время равномерно, параллельно выращивая из непосредственных разработчиков тоже лидов (команды собираются специально так, чтобы у сотрудников был потенциал роста). В пиковые моменты, например, когда один из проектов проходит важный релиз / демо, больше внимания уделяется одному из них. Но долгосрочно это норм, если система поставлена и работает, дисбаланс не возникат.
3. Коротко про код-ревью описал в следующем же абзаце. Продублирую:
«В командах, где больше 3 разработчиков, мы сознательно уходим от ревью тимлидом всех задач. Он проводит код-ревью только сложных, ответственных и больших задач, касающихся сложных модулей проекта. Остальные проверяются с помощью кросс-ревью. Однако тимлид должен выборочно просматривать задачи любой сложности и важности, чтобы оставаться в контексте всех частей проекта.»
Ужасно, ужасно, команда из 30 человек. Неужели такая заливка ресурсами хоть что-то ускоряет? Ещё брукс 30 лет назад писал, что не стоит так жестить, смысла никакого нет.
На самом деле, 30 человек — относительно небольшая команда. Приведу пример одного из проектов, в котором участвовал:
— 6 фронтендеров
— 6 бекендеров
— 3 менеджера
— 2 аналитика
— 3 дизайнера
— 2 QA
— плюс в нашем случае есть сторонние команды, которые разрабатывают модули и встраивают их в ядро, но интеграции настолько плотные, что обсуждения ведутся так, будто мы все в одной команде.
Уже набирается 30 человек точно
— в нашем случае был только веб, но в общем можно добавить к этой команде еще N мобильных разработчиков
— инфраструктурой в KTS занимается DevOps отдел, поэтому их не включаем, но опять же в зависимости от задач и специфики иерархии, DevOps-инженеры тоже могу входить в команду
В общем, 30 человек вполне можно переварить, если грамотно декомпозировать роли и выстроить коммуникацию. Еще нужно сделать механизмы интеграции процессов более независимыми, тогда растить команду можно практически неограниченно.
Про этот проект есть стать на хабре, кстати, если любопытно, предлагаю изучить: https://habr.com/ru/company/kts/blog/569448/
Сколько компаний, столько вариантов понимания кто такой тимлид.
То что я вижу, тимлид - это что-то вроде локального HR на команду: время считает, на счёт отпуска договаривается, пьянку организовать - это совершенно не техническая роль и отвечает за команду.
За задачи отвечает Product owner, за ревью и прочие технические вещи техлид.
Вот уж точно, у каждого свое понимание - у нас всем этим занимается менеджер, а тимлид у нас техлид по вашему. Да и в литературе часто пишут тимлид/техлид - видимо никто точно не знает как их называть.
Здравствуйте! В нашем случае тимлид ближе к технической составляющей, как упоминал @Kragius: отпуска и организация пьянок — точно не его обязанность в KTS ?
Понятно, что зависит от уровня команды, но чем дальше тем больше — я склоняюсь к тому, что декомпозировать должна команда. Тимлид и менеджер должны организовать и поддерживать этот процесс. Как базовый принцип — я принял бы, что в разработке — каждый участник процесса на своем уровне обязан сам создать себе тикет, а руководитель должен его максимум согласовать (и то, по принципу «не возражает — значит согласен»). То есть, в терминах agile — pull, а не push задач. Тикет уровня N+1 для разработчиков на уровне N — является целью, а не руководством к действию. Уровень N по этому поводу делает себе один или несколько тикетов, которые являются шагами для достижения обозначенной цели, и эти шаги являются целью для уровня N-1. И так до тех пор, пока не дойдет до исполнителей. Иначе в системе слишком много ответственности наверху, слишком мало ума внизу, и непонятно как строить нормальную обратную связь для процесса разработки.
Я бы все-таки назначил на тимлида обязанности балансировать и развивать команду, организовывать решение технических вопросов, а главное — тимлид является своим собственным «резервом главного командования». Если где-то в команде затык (а сроки никто не отменял) — он подключается личным ресурсом и обеспечивает решение задачи без нарушения общего рабочего ритма. Кроме того, на нем же, скорее всего будет лежать всякая нетривиальная работа типа проверки новых концепций и гипотез (на уровне реализации, а не всего продукта) — то есть там, где проще договориться с самим собой внутри головы, чем тратить время на коммуникацию еще неоформленной и смутной идеи до других членов команды…
Здравствуйте! Согласен с тем, что одна из обязанностей тимлида в развитии команды. Подключение сотрудников к планированиям, декомпозиции и пр. — это тоже один из процессов развития сотрудников и не противоречит содержанию статьи.
Например, менеджер может без участия тимлида пригласить разработчика для декомпозиции какого-то раздела. Разработчик прокачивается, но ответственным за процесс остается именно менеджер. Так же и с лидом, он может делегировать проектирование архитектуры, но ответственность за конечный результат всё равно на лиде.
Немного не согласен с тем, что инициатива должна исходить от разработчика вплоть до создания тикета, потому что здесь может начаться хаос и дублирование задач. Хочется, чтобы был какой-то центр фиксации решений, а вот к процессам, конечно, нужно подключать сотрудников, чтобы они в них вникали, понимали контекст, предпосылки, ограничения, и принимали решения.
Более того, согласен с тем, что нужно поощрять инициативу сотрудников и давать им возможность реализовать свою идею до конца, в том числе с вовлечением других коллег. Но опять же, всё это должно проходить через контроль менеджера и лида, чтобы у них оставалось глубокое понимание процессов на проекте.
Уже появились отличия тимлидов и техлидов в вакансиях, особенно в компаниях покрупнее.
Вообще непонятно зачем нужен тимлид при менеджере, или менеджер при тимлиде? Размытые зоны ответственности, непонятные регалии, на ровном месте появляется 2 уровня иерархии. Зачем?
Здравствуйте! На самом деле, дело не в регалиях. Базовый принцип я бы сформировал так: увеличиваем эффективность труда сотрудника за счет спецификации его основных обязанностей. Тимлиду — тимлидово, менеджеру — менеджерово ?.
Тимлид отвечает за:
— техническое качество
— сроки реализации задач
— развитие команды
— технические процессы в команде
— эффективное распределение нетиповых задач
Менеджер отвечает за:
— коммуникацию — это в первую очередь, на мой взгляд, т.к. количественно самая объемная работа с самым большим контекстом, который нужно помнить
— планирование работ
— декомпозицию и распределение типовых задач
В этом случае, конечно, возникают издержки на коммуникацию, поэтому она должна быть эффективной, а для этого нужно выстраивать процессы, чтобы каждый человек понимал свою зону ответственности. Нужно понимать, как без блокировок решить проблему, если менеджер или тимлид сейчас не могут сделать свою работу.
Ровно поэтому тимлид должен также разбираться и в работе менеджера, а менеджер должен уметь что-то из работы тимлида: например, если тимлид выпал на полдня, менеджер должен и без него примерно осознавать возможную сложность нетиповых задач и грамотно их распределить или понять, что их лучше отложить. А тимлид может вместо менеджера провести встречу и подвести её итоги. Но опять же, это скорее для лучшего понимания друг друга и выхода из нестандартных ситуаций.
Что НЕ должен делать тимлид — или сага о задачках в таск-трекере