Существует стереотип, что следующей ступенькой в карьере разработчика является должность тимлида. Бывший тимлид и консультант Александр Усков рассказывает, что это значит — быть тимлидом, и действительно ли программисту необходимо им становиться.
- Как это вообще — быть тимлидом?
- Качество продукта — теперь ваше дело
- Все проблемы команды — теперь ваши проблемы
- Писать код — теперь не обязанность, а роскошь
- Интересы бизнеса — теперь и ваши интересы
- Придется много общаться с людьми
- Тимлидов редко ищут там, где нет проблем
- Это просто весьма утомительная работа
Как гласит народный афоризм, ошибочно приписываемый Александру Суворову, плох тот солдат, который не мечтает стать генералом. Не можем уверенно утверждать, что на военной службе дела обстоят именно так, но в разработке программного обеспечения точно все не так однозначно.
Помимо очевидного факта, что руководителей требуется значительно меньше, чем подчиненных, и, возможно, менее очевидного, что не у всех сотрудников хватает компетенции и навыков для работы в качестве управленца, есть еще и иная сторона вопроса: далеко не все разработчики мечтают о росте в менеджерскую вертикаль. А те, кто мечтают, не всегда осознают, что им это сулит. Бывают даже случаи, когда разработчик пробует себя в качестве руководителя группы, а потом, получив этот опыт, предпочитает вернуться к жизни инженера и продолжить развиваться исключительно в прикладных технических навыках.
Как это вообще — быть тимлидом?
В мире промышленной разработки софта существует великое множество различных должностей, позиций и терминов для описания технических менеджеров — руководителей, среди подчиненных которых нет других руководителей. К ним относится и позиция лидера команды во всех ее видах. Несмотря на многообразие названий этой должности в российской IT-культуре — Team Lead, Lead Developer, Head of …, руководитель группы/команды/направления и даже «Лидер по IT», — от человека в данной роли везде ожидаются примерно одинаковые функции:
- Коммуникация между производственной командой и внешними (по отношению к команде) коллегами, заказчиками и вышестоящими руководителями
- Управление потоком задач, которые поступают в команду, и контроль за их выполнением. Сюда же — принятие необходимых технических решений
- Непосредственное управление выделенными на команду ресурсами — как человеческими, так и материальными, оптимизация производственного процесса
- Оперативное решение проблем или, при невозможности их решения, передача их вышестоящим руководителям
- Повышение производительности команды, профессиональный рост ее участников и трансляция их интересов бизнесу.
Детали могут отличаться в зависимости от размера компании и процессов. Какие-то из этих функций могут осуществляться совместно с другими ролями, например, менеджеры проектов, менеджеры по продукту, аналитики, архитекторы.
Неизменным остается то, что тимлид руководит командой, которая непосредственно осуществляет производственный процесс — будь то разработчики, тестировщики или полноценная кросс-функциональная команда, также известная как “Agile feature team”.
Из этих функций вытекают некоторые особенности, которые существенно отличают рабочий процесс тимлида от линейного разработчика. Давайте рассмотрим некоторые изменения, которые произойдут в вашей профессиональной деятельности, если вы решите принять подобную ответственность.
Качество продукта — теперь ваше дело
Теперь вас будут спрашивать, если на вашем участке работы возникли технические проблемы — особенно если это повлекло за собой финансовые или репутационные риски для бизнеса. Если авария случилась у вашей команды, то и ответственность будет лежать на ваших плечах.
Поэтому в ваших интересах обеспечивать качество реализуемых решений. С одной стороны, это дает вам небывалые возможности: теперь вы сможете решать задачи куда более высокого уровня, чем в роли линейного разработчика, имея для этого большой ассортимент средств. Вашими инструментами теперь являются не только фреймворки, платформы и программные комплексы, но и сами люди в вашей команде.
С большой вероятностью, именно вы будете принимать (если захотите, конечно) финальные решения об используемых технологиях, покрытии продукта тестами, архитектуре приложения, методологиях разработки. С другой стороны, как гласит древнейшая пословица (также известная как принцип Питера Паркера), — к большой власти прилагается большая ответственность, и все возможные негативные последствия этих решений, как технические, так и сугубо бизнесовые, вернутся к вам сторицей.
Например, разработчик что-то недосмотрел на этапе Code Review, и ваше приложение не прошло модерацию в App Store? Свежий релиз, напичканный новыми библиотеками, уронил прод? У каждого десятого юзера не нажимается кнопка, потому что вы решили не тестировать устаревшую операционную систему? В вашем проекте накопилось столько технического долга, что ваши сотрудники ошибаются в оценке даже простейших задач в несколько раз? Маркетинг закупил трафик на миллионы, а ваш сервис упал от нагрузки, тем самым уничтожив рекламный бюджет впустую? Даже если ни в одном из случаев это не ваша вина — все это ваша ответственность.
Кроме того, в крупных B2B и B2C продуктах разработка зачастую является одной из последних линий поддержки, и разнообразные хотелки, жалобы и претензии клиентов имеют все шансы попасть к вам на стол. Особенно если соответствующий департамент и/или менеджеры по работе с клиентами не обладают необходимой информацией или полномочиями по каким-либо вопросам.
Никогда не останавливайтесь: Извини, у меня самолет: как программисту стать цифровым кочевником и почему это сделает вашу жизнь лучше
Все проблемы команды — теперь ваши проблемы
В команде всегда найдутся те, кто не успел сделать задачу к дедлайну, решил уволиться, только присоединился к команде и еще ничего не понимает, хочет больше зарплату, просит другой график работы, или забывает отмечать время работы в Jira, ушел в отпуск и не оставил информацию по текущим задачам. Теперь это в том числе и ваши проблемы, и вам с ними жить.
Все, что вы регулярно наблюдали в качестве разработчика, но что решалось без вашего участия, теперь требует непосредственного вашего внимания, действий, учета рисков при планировании ресурсов и понимания, что вообще со всем этим делать. При этом нет какого-то стандартного решения таких проблем — они могут отличаться от команды к команде, и сформировать некий майндсет для принятия подобных решений можно только на опыте. Сталкиваясь с таким в первый раз, мало кто может среагировать не то что компетентно, а хотя бы просто адекватно. И очень здорово, если найдутся старшие товарищи, с которыми можно посоветоваться.
Поэтому вам понадобится немалая выдержка и некоторая личная психологическая зрелость, чтобы эти решения были не только эффективными, но и не требовали от вас чрезмерной нагрузки, в том числе и эмоциональной. Типичная (ошибочная) линия поведения начинающих руководителей — пытаться закрыть все дырки самостоятельно, своим ресурсом. Чаще всего это приводит к тому самому выгоранию, а научиться делегировать ответственность своим тиммейтам и понимать, где, что и кому можно доверить — важнейший для руководителя навык. И он обычно оттачивается годами.
Писать код — теперь не обязанность, а роскошь
Чем выше уровень специалиста в производственной иерархии, тем выше уровень и масштаб задач, которые он решает. Как прораб на стройке не кладет штукатурку, а главный инженер на заводе — не стоит за станком, так и тимлид не решает спринтовые задачи и не фиксит баги — во всяком случае, пока этого не требуют обстоятельства. В достаточно крупных инженерных компаниях это правило распространяется даже на линейных разработчиков высоких грейдов: тамошние сеньоры практически не пишут код, они пишут дизайн-документы, планы развития, емейлы, участвуют в встречах, обучают новобранцев.
В компаниях меньшего размера этим и занимается тимлид. Конечно, тимлиду не запрещают программировать — просто у него слишком много других забот. Побаловаться с кодом теперь получится только в свободное от всего остального время. Это одна из основных причин, по которым некоторые разработчики высокой квалификации отказываются от управленческих позиций, — чтобы продолжить повышать свою квалификацию именно в качестве программиста.
Конечно, стоит оговориться, что это сильно зависит от размера команды и организации — многие небольшие компании ищут в качестве тимлида типаж «играющего тренера». И на этой позиции менеджерские обязанности сочетаются с задачами программирования в плюс-минус равных пропорциях. Это очень хороший вариант для тех разработчиков, кто хочет примерить на себя шкурку менеджера, но не погружаться в этот омут сразу с головой.
Интересы бизнеса — теперь и ваши интересы
Наиболее значимым изменением в корпоративной жизни сотрудника при переходе с линейной должности на руководящую является необходимость выступать посредником различных интересов, которые вступают в противоречие друг с другом. В бизнес-процессах любого коммерческого производственного предприятия (к которым относятся и компании, разрабатывающие ПО) можно выделить три основных роли участников:
- Пользователи, они же клиенты. Они являются потребителем продукта и обеспечивают ему выручку. Их интересы включают в себя получение ценности с помощью предлагаемого им продукта. И именно их явные и неявные желания, ожидания и боли, связанные с этим продуктом, задают общее направление производственному процессу.
- Производство — люди, которые создают продукт — от разработчиков и тестировщиков до иллюстраторов и копирайтеров. В их сферы интересов входят качество и комфорт производственных процессов, условия труда, личный профессиональный рост, признание их заслуг компанией и разные личные амбиции.
- Бизнес — люди, которые являются владельцами или инвесторами компании. Они заинтересованы в рентабельности компании, репутации бренда, росте коллектива и производственных мощностей, а также в выполнении различных нормативов — например, в соблюдении законов и требований регулирующих организаций.
Это упрощенная схема — она в большей степени применима к продуктовым компаниям, где продукт рождается как раз в пересечении сфер интересов этих групп. С некоторыми уточнениями она может быть экстраполирована и на инженерные компании с другой бизнес-моделью. Взаимодействие этих групп с продуктом и друг другом можно представить в виде диаграммы Эйлера-Венна:
У каждой из групп есть как свои изолированные интересы, так и некоторые пересечения — линейные сотрудники производственного блока (не только разработчики, но и архитекторы, девопсы, тестировщики и другие, в чьи функции входит решение поставленных технологических задач) не обязаны учитывать, как их департамент взаимодействует с пользователями, продуктом и бизнесом. В то время как для тимлида это является неизбежным и едва ли не ключевым — ведь его функция уже не ограничивается исключительно производственным процессом.
Между бизнесом и производством всегда есть некоторый конфликт. Если упрощать и возводить в абсолют — бизнес всегда стремится получить максимум прибыли при минимуме расходов (включая расходы на производство, в том числе, оплату труда). В то время как люди, занятые разработкой, хотели бы зарабатывать как можно больше, а делать, — если не как можно меньше вообще, то хотя бы как можно меньше того, что им не хочется делать. Помимо этого разработчики хотят решать интересные для себя задачи — пробовать новые инструменты и технологии, делать что-то сверх требуемого минимума, писать тесты, рефакторить неудобный код и другим образом творчески самореализовываться. Бизнес же рад отказаться от всех возможных лишних трат времени и ресурса и хотел бы добавлять как можно больше ценности в продукт в единицу времени.
Поэтому невозможно переоценить роль тимлида в взаимодействии между ними — именно он является медиатором и точкой, в которой эти, зачастую противоположные, группы должны сойтись к некоторому общему знаменателю. Именно он ответственен за то, чтобы в каждом отдельном случае найти компромисс и по максимуму удовлетворить потребности всех сторон.
Это ответственность, и она требует большого списка софт-скиллов — необходимо хорошо слушать, и убеждать, и доносить свою позицию до людей с разной подготовкой, независимо от их положения в иерархии, и знать, где и чем придется пожертвовать (это неизбежно). Тем, кто попадает в руководители из непосредственно разработчиков, в начале бывает очень сложно — они не привыкли мыслить в такой парадигме.
Придется много общаться с людьми
Тимлид — должность в первую очередь про коммуникацию. В некотором роде он является прокси между своей командой и внешним миром, пропуская через себя колоссальные объемы информации и поддерживая взаимодействие с немалым количеством людей.
Чем крупнее компания, тем больше круг контактов у такого руководителя. Часто он в несколько раз больше, чем его собственная команда. В дополнение к этому, выход на уровень управления автоматически означает, что придется так или иначе соприкоснуться с внутрикорпоративной политикой — попасть в отдельный слой отношений между сотрудниками компании, который не регламентируется и не регулируется только лишь профессиональными обязанностями и этикой. Это, на самом деле, вещь в себе, и далеко не всем комфортно, удобно и приятно с этим соприкасаться. В больших же компаниях с высоким уровнем внутренней конкуренции вообще нужно держать ухо востро, потому что ваши интересы неизбежно будут входить в конфликт с интересами кого-то еще, со всеми вытекающими последствиями.
Никогда не останавливайтесь: Гайд по Nest.js: что это такое и как написать свой первый код
Все люди разные, не все одинаково компетентны и осведомлены о деталях рабочего процесса, не со всеми общение может складываться легко и непринужденно. С некоторыми вообще может возникать явный конфликт, при этом задачи как-то решать все равно придется. Кроме того, нередко приходится отстаивать собственное мнение и право провести те или иные свои решения — и этот навык является одним из абсолютно необходимых для тимлида, и именно его отсутствие часто является причиной отказа в повышении до этой позиции.
Тимлидов редко ищут там, где нет проблем
Как показывают различные кадровые исследования, большинство компаний предпочитает растить тимлидов внутри, из уже имеющихся специалистов. Причины этого достаточно прозаичны — тимлиду для эффективной работы нужно иметь огромное количество «внутренних» знаний о конкретной предметной области, продукте, команде и компании. И порой аккумулировать эти данные приходится годами. Передать их все человеку «с улицы» крайне трудно, для этого в компании должен быть специально поставленный процесс онбординга сотрудников, и далеко не все компании вообще могут себе это позволить, либо не считают это целесообразным. А вот нужда в руководителях команд назревает крайне быстро — практически в любой компании, где больше 10 человек, как минимум один такой специалист необходим.
Если команда собирается с нуля, то вариант с повышением кого-то из топовых разработчиков отсутствует, и приходится проводить отбор с рынка. С точки зрения потенциального кандидата — это лучший вариант. Как раз из-за того, что проект еще новый — в нем не накопился техдолг, мало легаси, все люди новые (между ними нет сложившихся неформальных отношений), и можно отлично себя зарекомендовать.
В сложившихся компаниях, если не получилось найти подходящего специалиста внутри, и приходится искать его снаружи, нередко можно диагностировать какие-то провалы в процессах, рабочих отношениях или экономической модели. Они еще обильно сдобрены немалым количеством контр-продуктивных практик, которые реализуются по инерции, потому что так принято.
И обо всем этом на собеседовании никто будущему руководителю рассказывать не поспешит. Это добавляет ответственности потенциальному тимлиду уже на стадии собеседования — если не задать правильные вопросы и не идентифицировать предстоящие проблемы, то после получения этой должности можно столкнуться и с непреодолимыми проблемами, которые значительно попортят опыт работы и желание продолжать сотрудничество.
Это просто весьма утомительная работа
Как можно догадаться по описанному списку разнообразных проблем, которые так или иначе одним из концов упираются в тимлида, на этой позиции человек сталкивается с очень серьезной нагрузкой. Как справедливо пишет википедия:
Исследования показывают, что работа руководителя низового звена является напряженной и наполненной разнообразными действиями. Она характеризуется частыми перерывами, переходами от одной задачи к другой. Задачи сами по себе потенциально краткие: в одном исследовании обнаружено, что время, затрачиваемое мастером в среднем на выполнение одного задания равнялось 48 секундам. Временной период для реализации решений, принимаемых мастером, также короткий.
Для успешного выполнения требований от тимлида требуется, во-первых, держать в голове много мелких деталей о принципах работы продукта и используемых в нем технологий. Во-вторых — умение контролировать одновременно кратко-, средне- и долгосрочные вопросы, регулярно переключаясь между ними. Это в свою очередь влечет очень высокие требования к навыку управлению собственным временем. В относительно успешном продукте у тимлида много открытых вопросов, которые он должен решить. И их всегда больше, чем он успевает обработать. Поэтому важно умение их грамотно приоритизировать и приложить нужные усилия в нужный момент.
Гипотетически, вы всегда можете найти крайнего среди своих подчиненных и озадачить его. Однако руководители, систематически решающие проблемы именно таким образом, не пользуются большим уважением ни у коллег, ни у членов команды, и имеют мало шансов продвинуться дальше в управленческой вертикали.
Выводы
Поскольку мы в этой статье сфокусировались на сложностях, с которыми сталкивается тимлид, может сложиться впечатление, что это неблагодарная и чрезмерно тяжелая работа. На самом деле — это соразмерная плата за огромный пласт очень полезного опыта, новые точки личного и профессионального роста, возможность в куда большей степени влиять на продукт. И самое главное, — за возможность решать более сложные и менее типовые задачи, а ведь это один из главных мотиваторов любого инженера и одна из движущих сил, сделавших многих из нас разработчиками.
Абсолютно точно не стоит ее бояться, надо лишь здраво оценивать свои возможности и соизмерять их с теми ожиданиями, которые к вам предъявляет эта должность. Кроме того, разумно предположить, что чем выше ответственность, тем выше предполагается за нее и компенсация.
Оправдывает ли себя эта ответственность и сопутствующая ей смена условий работы — каждый решает сам. Есть немало других направлений профессионального развития, не включающих в себя менеджерские функции. А может быть вы прочитали это и поняли, что это именно то, чего вы хотите? В таком случае мы можем лишь поддержать подобные устремления и пожелать удачи на этом нелегком пути.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
