Осенью я был на митапе, посвящённом scrum'у. И услышал там интересный тезис: в слаженной скрам-команде роль тимлида/техлида минимальна, потому что все участники команды в той или иной степени являются носителями знаний и прекрасно самоорганизовываются благодаря скраму.
Дисклеймер
В этой статье я не пытаюсь убедить, а скорее рассуждаю на тему и приглашаю к обсуждению в комментариях. И да, я недавно выгорел как тимлид, что придало тексту соответствующий эмоциональный окрас, так что не стоит судить строго.
Team leader, тимлид, ведущий разработчик — это специалист (программист, дизайнер, тестировщик и т.п.), который взял на себя обязанность руководить командой специалистов в той же области.
Однако, на практике, тимлид может заниматься и аналитикой, архитектурой, тестированием выполненных задач, проектированием интерфейсов. И швец, и жнец, и на дуде игрец. Мне доводилось видеть тимлида, который следил за отзывами на приложения в Google Play, App Store и отвечал на отзывы, то есть по сути занимался поддержкой пользователей. При этом хорошим тоном для лида считается непосредственное участие в разработке.
Из этого можно сделать вывод, что тимлид — это сеньор, который предпочёл основной своей деятельности менеджмент и другие активности. Для одних рост в тимлиды — это глоток свежего воздуха, удовлетворение амбиций и, возможно, способ избежать выгорания. Для других тимлидство — бремя, которое естественным образом свалилось как на самого опытного участника команды (впрочем, вместе с прибавкой к зарплате) и наоборот приводит к выгоранию.
Обязанности тимлида размыты и меняются от команды к команде, от компании к компании. Но объединяет все эти активности одно: в современной разработке эти обязанности, так или иначе, можно распределить между участниками команды, снизив необходимость в лидере.
Руководитель
В скраме есть три основные роли: владелец продукта, scrum-мастер и исполнители (дизайнеры, тестировщики, разработчики и т.п.). Причём роль scrum-мастера обычно отводится одному из исполнителей, либо владельцу продукта, что не так правильно.
Кто же в данном случае является руководителем команды? Владелец продукта — это скорее инициатор созвонов, источник задач, заказчик, принимающий работу. Scrum-мастер — модератор созвонов для груминга, оценки задач, ретроспективы, демо и т.п. Исполнители — исполнители. Скрам подход не выделяет какую-то роль как главенствующую, все роли одинаково важны. Куда же мы «воткнём» нашего руководителя-тимлида? Кажется, что место ему среди исполнителей, но в чём будет заключаться руководящая роль?
Формулирует задачи владелец продукта, за техническое наполнение задач отвечает аналитик, декомпозицией задач, выяснением деталей занимается команда во время груминга. Оценкой задач занимается команда, ретроспектива — чисто командная движуха, демо проводит один-два участника команды. Распределить задачи между собой вполне способна сама команда. Кем же и чем же руководит тимлид? Есть такая профессия «руками водить».
Хранитель знаний
Допустим, тимлид является самым компетентным специалистом в команде, носит в своей голове большой объём технических знаний и к нему приходят за этими знаниями другие участники.
Во-первых, это роль техлида. Во-вторых, и техлид не нужен: бизнесу куда полезнее, когда все технические знания распределены между членами команды, а не находятся у одного человека. Это снижает бас-фактор, делает коллективную оценку времени выполнения задач точнее, позволяет быстрее и проще масштабировать команду.
Учитывая современную тенденцию нанимать в проект лидов со стороны, а не выращивать их в команде, среднестатистический тимлид уже и не является хранителем технических знаний.
Связующее звено
Сейчас модно отводить тимлидам роль связующего звена (в просторечии «передаста») между бизнесом и разработчиками. В этой ипостаси тимлид отстаивает позицию команды и/или бизнеса. В целом, работа заключается в бесконечных созвонах, а главным рабочим инструментом вместо среды разработки становятся календарь и почта.
Но разве конфликт между заказчиком и исполнителем не должен решаться во время груминга, на котором исполнители могут доходчиво объяснить, почему реализация конкретной задачи займёт слишком много времени? Именно во время груминга происходит диалог бизнеса и исполнителя, именно тут должен рождаться компромисс.
В процессе решения задачи, если у исполнителя возникают какие-то вопросы, гораздо эффективнее обсудить проблемы лично с дизайнером/тестировщиком/менеджером, чем общаться через лида — это ненужный посредник.
Администратор
Тимлид обычно наделён административными правами: выдача доступов, решения о найме/увольнении, решения о премировании, повышении зарплаты и т.д.
Наверное, это единственная по-настоящему полезная функция тимлида, т.к. в теории лид является персонажем, максимально приближенным к команде. Кроме того, за счёт наличия административных прав тимлид получает безусловный авторитет и позицию начальника в отношениях «начальник-подчинённый».
При этом наличие начальника — это не только способ контроля исполнителей, но и раздражающий фактор для них же. Потому что при отлаженных процессах, взаимной ответственности и здоровой атмосфере в коллективе тимлиду, как контролирующей инстанции, не остаётся работы, всё функционирует и без него.
Что касается найма сотрудников, то рекомендацию о найме должны давать интервьюеры на основании результата собеседования. Конечное решение вполне может на себя взять технический директор.
Процессы выдачи доступов, по-идее, должны инициироваться при трудоустройстве и осуществляться системными администраторами.
Премирование, повышение зарплаты, увольнение — такие решения удобно принимать менеджменту/техническому директору на основе оценки 360 градусов.
Тестировщик, аналитик, архитектор
Заголовок говорит сам за себя — это отдельные роли для отдельных специалистов. Однако, в компании не всегда есть выделенные специалисты для этих активностей. Если у лида есть чувство повышенной ответственности за проект, то он может по доброй воле взять на себя работу, для которой нет выделенной должности. В результате чужие, по сути, обязанности закрепляются за должностью лида. Члены команды, менеджмент, руководство, насмотревшись на такой пример, будут считать, что и любой другой лид должен исполнять эти обязанности.
Исследователь и инноватор
Раз тимлид в связи со своими активностями освобождается от обязательного написания кода в рамках спринтов, то в редкие моменты между созвонами, он может посвятить себя написанию чего-то фундаментального, решению какой-то сложной проблемы, до которой у других не доходят руки, либо написанию статьи на Хабр.
Но решением сложных проблем, написанием рокет-сайенс кода должен заниматься R&D специалист. А писать статьи на Хабр должны все те члены команды, кто хочет этим заниматься, проявляет инициативу.
Ну, допустим. А куда расти?
Немного расскажу о своём опыте тимлидства. У меня, как тимлида, всегда стояла задача собирать команду с нуля и в этой роли основателя было комфортно. Но когда начиналась работа с командой, я каждый раз немного выгорал. В основном из-за того, что мне приходилось отвлекаться от своего любимого программирования на работу с людьми, удовольствия от которой я не получал.
Каждый раз, когда я увольнялся, говорил себе, что «больше не буду тимлидом, это не моё». Но получалось становиться лидом впоследствии органически — когда появлялась необходимость в команде.
Но последнее место работы стало исключением — я пришёл лидом в уже слаженную сильную команду, а моя деятельность сводилась к созвонам и коммуникации в чатах. Это позволило мне словить, пожалуй, самый большой синдром самозванца за всю карьеру и выгореть как лиду окончательно.
Передо мной встал вопрос: а куда расти, если я для себя окончательно решил не быть лидом? За ответом далеко идти не приходится. Можно качать экспертизу, можно писать статьи, вести блог, можно участвовать в опенсорсе, можно самому основать какой-то проект, можно плотнее заняться хобби. Если вы упёрлись в потолок по зарплате как специалист, совсем необязательно перетекать в менеджмент в поисках большего дохода. Доход можно увеличить и другими способами. И точка.
P.S. Не лишним будет сказать, что у меня есть Telegram-канал «IT Монах», приглашаю подписаться :)
