Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-26

1 <p><strong>Существует стереотип, что следующей ступенькой в карьере разработчика является должность тимлида. Бывший тимлид и консультант Александр Усков рассказывает, что это значит - быть тимлидом, и действительно ли программисту необходимо им становиться.</strong></p>

2 <p>Как гласит народный афоризм, ошибочно приписываемый Александру Суворову, плох тот солдат, который не мечтает стать генералом. Не можем уверенно утверждать, что на военной службе дела обстоят именно так, но в разработке программного обеспечения точно все не так однозначно.</p>

3 <p>Помимо очевидного факта, что руководителей требуется значительно меньше, чем подчиненных, и, возможно, менее очевидного, что не у всех сотрудников хватает компетенции и навыков для работы в качестве управленца, есть еще и иная сторона вопроса: далеко не все разработчики мечтают о росте в менеджерскую вертикаль. А те, кто мечтают, не всегда осознают, что им это сулит. Бывают даже случаи, когда разработчик пробует себя в качестве руководителя группы, а потом, получив этот опыт, предпочитает вернуться к жизни инженера и продолжить развиваться исключительно в прикладных технических навыках.</p>

4 <h2>Содержание</h2>

5 <ul><li><a>Как это вообще - быть тимлидом?</a></li>

6 <li><a>Качество продукта - теперь ваше дело</a></li>

7 <li><a>Все проблемы команды - теперь ваши проблемы</a></li>

8 <li><a>Писать код - теперь не обязанность, а роскошь</a></li>

9 <li><a>Интересы бизнеса - теперь и ваши интересы</a></li>

10 <li><a>Придется много общаться с людьми</a></li>

11 <li><a>Тимлидов редко ищут там, где нет проблем</a></li>

12 <li><a>Это просто весьма утомительная работа</a></li>

13 <li><a>Выводы</a></li>

14 </ul><h2>Как это вообще - быть тимлидом?</h2>

15 <p>В мире промышленной разработки софта существует великое множество различных должностей, позиций и терминов для описания технических менеджеров - руководителей, среди подчиненных которых нет других руководителей. К ним относится и позиция лидера команды во всех ее видах. Несмотря на многообразие названий этой должности в российской IT-культуре - Team Lead, Lead Developer, Head of …, руководитель группы/команды/направления и даже "Лидер по IT", - от человека в данной роли везде ожидаются примерно одинаковые функции:</p>

16 <ul><li>Коммуникация между производственной командой и внешними (по отношению к команде) коллегами, заказчиками и вышестоящими руководителями</li>

17 <li>Управление потоком задач, которые поступают в команду, и контроль за их выполнением. Сюда же - принятие необходимых технических решений</li>

18 <li>Непосредственное управление выделенными на команду ресурсами - как человеческими, так и материальными, оптимизация производственного процесса</li>

19 <li>Оперативное решение проблем или, при невозможности их решения, передача их вышестоящим руководителям</li>

20 <li>Повышение производительности команды, профессиональный рост ее участников и трансляция их интересов бизнесу.</li>

21 </ul><p>Детали могут отличаться в зависимости от размера компании и процессов. Какие-то из этих функций могут осуществляться совместно с другими ролями, например, менеджеры проектов, менеджеры по продукту, аналитики, архитекторы.</p>

22 <p>Неизменным остается то, что тимлид руководит командой, которая непосредственно осуществляет производственный процесс - будь то разработчики, тестировщики или полноценная кросс-функциональная команда, также известная как “Agile feature team”.</p>

23 <p>Из этих функций вытекают некоторые особенности, которые существенно отличают рабочий процесс тимлида от линейного разработчика. Давайте рассмотрим некоторые изменения, которые произойдут в вашей профессиональной деятельности, если вы решите принять подобную ответственность.</p>

24 <h2>Качество продукта - теперь ваше дело</h2>

25 <p>Теперь вас будут спрашивать, если на вашем участке работы возникли технические проблемы - особенно если это повлекло за собой финансовые или репутационные риски для бизнеса. Если авария случилась у вашей команды, то и ответственность будет лежать на ваших плечах.</p>

26 <p>Поэтому в ваших интересах обеспечивать качество реализуемых решений. С одной стороны, это дает вам небывалые возможности: теперь вы сможете решать задачи куда более высокого уровня, чем в роли линейного разработчика, имея для этого большой ассортимент средств. Вашими инструментами теперь являются не только фреймворки, платформы и программные комплексы, но и сами люди в вашей команде.</p>

27 <p>С большой вероятностью, именно вы будете принимать (если захотите, конечно) финальные решения об используемых технологиях, покрытии продукта тестами, архитектуре приложения, методологиях разработки. С другой стороны, как гласит древнейшая пословица (также известная как<a>принцип Питера Паркера</a>), - к большой власти прилагается большая ответственность, и все возможные негативные последствия этих решений, как технические, так и сугубо бизнесовые, вернутся к вам сторицей.</p>

28 - <p>Например, разработчик что-то недосмотрел на этапе Code Review, и ваше приложение не прошло модерацию в App Store? Свежий релиз, напичканный новыми библиотеками, уронил прод? У каждого десятого юзера не нажимается кнопка, потому что вы решили не тестировать устаревшую операционную систему? В вашем проекте накопилось столько технического долга, что ваши сотрудники ошибаются в оценке даже простейших задач в несколько раз? Маркетинг закупил трафик на миллионы, а ваш сервис упал от нагрузки, тем самым уничтожив рекламный бюджет впустую? Даже если ни в одном из случаев это не ваша вина - все это ваша ответственность.</p>

28 + <p>Например, разработчик что-то недосмотрел на этапе Code Review, и ваше приложение не прошло модерацию в App Store? Свежий релиз, напичканный новыми библиотеками, уронил прод? У каждого десятого юзера не нажимается кнопка, ��отому что вы решили не тестировать устаревшую операционную систему? В вашем проекте накопилось столько технического долга, что ваши сотрудники ошибаются в оценке даже простейших задач в несколько раз? Маркетинг закупил трафик на миллионы, а ваш сервис упал от нагрузки, тем самым уничтожив рекламный бюджет впустую? Даже если ни в одном из случаев это не ваша вина - все это ваша ответственность.</p>

29 <p>Кроме того, в крупных B2B и B2C продуктах разработка зачастую является одной из последних линий поддержки, и разнообразные хотелки, жалобы и претензии клиентов имеют все шансы попасть к вам на стол. Особенно если соответствующий департамент и/или менеджеры по работе с клиентами не обладают необходимой информацией или полномочиями по каким-либо вопросам.</p>

30 <h2>Все проблемы команды - теперь ваши проблемы</h2>

31 <p>В команде всегда найдутся те, кто не успел сделать задачу к дедлайну, решил уволиться, только присоединился к команде и еще ничего не понимает, хочет больше зарплату, просит другой график работы, или забывает отмечать время работы в Jira, ушел в отпуск и не оставил информацию по текущим задачам. Теперь это в том числе и ваши проблемы, и вам с ними жить.</p>

32 <p>Все, что вы регулярно наблюдали в качестве разработчика, но что решалось без вашего участия, теперь требует непосредственного вашего внимания, действий, учета рисков при планировании ресурсов и понимания, что вообще со всем этим делать. При этом нет какого-то стандартного решения таких проблем - они могут отличаться от команды к команде, и сформировать некий майндсет для принятия подобных решений можно только на опыте. Сталкиваясь с таким в первый раз, мало кто может среагировать не то что компетентно, а хотя бы просто адекватно. И очень здорово, если найдутся старшие товарищи, с которыми можно посоветоваться.</p>

33 <p>Поэтому вам понадобится немалая выдержка и некоторая личная психологическая зрелость, чтобы эти решения были не только эффективными, но и не требовали от вас чрезмерной нагрузки, в том числе и эмоциональной. Типичная (ошибочная) линия поведения начинающих руководителей - пытаться закрыть все дырки самостоятельно, своим ресурсом. Чаще всего это приводит к тому самому выгоранию, а научиться делегировать ответственность своим тиммейтам и понимать, где, что и кому можно доверить - важнейший для руководителя навык. И он обычно оттачивается годами.</p>

34 <h2>Писать код - теперь не обязанность, а роскошь</h2>

35 <p>Чем выше уровень специалиста в производственной иерархии, тем выше уровень и масштаб задач, которые он решает. Как прораб на стройке не кладет штукатурку, а главный инженер на заводе - не стоит за станком, так и тимлид не решает спринтовые задачи и не фиксит баги - во всяком случае, пока этого не требуют обстоятельства. В достаточно крупных инженерных компаниях это правило распространяется даже на линейных разработчиков высоких грейдов: тамошние сеньоры практически не пишут код, они пишут дизайн-документы, планы развития, емейлы, участвуют в встречах, обучают новобранцев.</p>

36 <p>В компаниях меньшего размера этим и занимается тимлид. Конечно, тимлиду не запрещают программировать - просто у него слишком много других забот. Побаловаться с кодом теперь получится только в свободное от всего остального время. Это одна из основных причин, по которым некоторые разработчики высокой квалификации отказываются от управленческих позиций, - чтобы продолжить повышать свою квалификацию именно в качестве программиста.</p>

37 <p>Конечно, стоит оговориться, что это сильно зависит от размера команды и организации - многие небольшие компании ищут в качестве тимлида типаж "играющего тренера". И на этой позиции менеджерские обязанности сочетаются с задачами программирования в плюс-минус равных пропорциях. Это очень хороший вариант для тех разработчиков, кто хочет примерить на себя шкурку менеджера, но не погружаться в этот омут сразу с головой.</p>

38 <h2>Интересы бизнеса - теперь и ваши интересы</h2>

39 <p>Наиболее значимым изменением в корпоративной жизни сотрудника при переходе с линейной должности на руководящую является необходимость выступать посредником различных интересов, которые вступают в противоречие друг с другом. В бизнес-процессах любого коммерческого производственного предприятия (к которым относятся и компании, разрабатывающие ПО) можно выделить три основных роли участников:</p>

40 <ul><li>Пользователи, они же клиенты. Они являются потребителем продукта и обеспечивают ему выручку. Их интересы включают в себя получение ценности с помощью предлагаемого им продукта. И именно их явные и неявные желания, ожидания и боли, связанные с этим продуктом, задают общее направление производственному процессу.</li>

41 <li>Производство - люди, которые создают продукт - от разработчиков и тестировщиков до иллюстраторов и копирайтеров. В их сферы интересов входят качество и комфорт производственных процессов, условия труда, личный профессиональный рост, признание их заслуг компанией и разные личные амбиции.</li>

42 <li>Бизнес - люди, которые являются владельцами или инвесторами компании. Они заинтересованы в рентабельности компании, репутации бренда, росте коллектива и производственных мощностей, а также в выполнении различных нормативов - например, в соблюдении законов и требований регулирующих организаций.</li>

43 </ul><p>Это упрощенная схема - она в большей степени применима к продуктовым компаниям, где продукт рождается как раз в пересечении сфер интересов этих групп. С некоторыми уточнениями она может быть экстраполирована и на инженерные компании с другой бизнес-моделью. Взаимодействие этих групп с продуктом и друг другом можно представить в виде диаграммы Эйлера-Венна:</p>

44 <p>У каждой из групп есть как свои изолированные интересы, так и некоторые пересечения - линейные сотрудники производственного блока (не только разработчики, но и архитекторы, девопсы, тестировщики и другие, в чьи функции входит решение поставленных технологических задач) не обязаны учитывать, как их департамент взаимодействует с пользователями, продуктом и бизнесом. В то время как для тимлида это является неизбежным и едва ли не ключевым - ведь его функция уже не ограничивается исключительно производственным процессом.</p>

45 <p>Между бизнесом и производством всегда есть некоторый конфликт. Если упрощать и возводить в абсолют - бизнес всегда стремится получить максимум прибыли при минимуме расходов (включая расходы на производство, в том числе, оплату труда). В то время как люди, занятые разработкой, хотели бы зарабатывать как можно больше, а делать, - если не как можно меньше вообще, то хотя бы как можно меньше того, что им не хочется делать. Помимо этого разработчики хотят решать интересные для себя задачи - пробовать новые инструменты и технологии, делать что-то сверх требуемого минимума, писать тесты, рефакторить неудобный код и другим образом творчески самореализовываться. Бизнес же рад отказаться от всех возможных лишних трат времени и ресурса и хотел бы добавлять как можно больше ценности в продукт в единицу времени.</p>

46 <p>Поэтому невозможно переоценить роль тимлида в взаимодействии между ними - именно он является медиатором и точкой, в которой эти, зачастую противоположные, группы должны сойтись к некоторому общему знаменателю. Именно он ответственен за то, чтобы в каждом отдельном случае найти компромисс и по максимуму удовлетворить потребности всех сторон.</p>

47 <p>Это ответственность, и она требует большого списка софт-скиллов - необходимо хорошо слушать, и убеждать, и доносить свою позицию до людей с разной подготовкой, независимо от их положения в иерархии, и знать, где и чем придется пожертвовать (это неизбежно). Тем, кто попадает в руководители из непосредственно разработчиков, в начале бывает очень сложно - они не привыкли мыслить в такой парадигме.</p>

48 <h2>Придется много общаться с людьми</h2>

49 <p>Тимлид - должность в первую очередь про коммуникацию. В некотором роде он является прокси между своей командой и внешним миром, пропуская через себя колоссальные объемы информации и поддерживая взаимодействие с немалым количеством людей.</p>

50 <p>Чем крупнее компания, тем больше круг контактов у такого руководителя. Часто он в несколько раз больше, чем его собственная команда. В дополнение к этому, выход на уровень управления автоматически означает, что придется так или иначе соприкоснуться с внутрикорпоративной политикой - попасть в отдельный слой отношений между сотрудниками компании, который не регламентируется и не регулируется только лишь профессиональными обязанностями и этикой. Это, на самом деле, вещь в себе, и далеко не всем комфортно, удобно и приятно с этим соприкасаться. В больших же компаниях с высоким уровнем внутренней конкуренции вообще нужно держать ухо востро, потому что ваши интересы неизбежно будут входить в конфликт с интересами кого-то еще, со всеми вытекающими последствиями.</p>

51 <p>Все люди разные, не все одинаково компетентны и осведомлены о деталях рабочего процесса, не со всеми общение может складываться легко и непринужденно. С некоторыми вообще может возникать явный конфликт, при этом задачи как-то решать все равно придется. Кроме того, нередко приходится отстаивать собственное мнение и право провести те или иные свои решения - и этот навык является одним из абсолютно необходимых для тимлида, и именно его отсутствие часто является причиной отказа в повышении до этой позиции.</p>

52 <h2>Тимлидов редко ищут там, где нет проблем</h2>

53 <p>Как показывают различные кадровые исследования, большинство компаний предпочитает растить тимлидов внутри, из уже имеющихся специалистов. Причины этого достаточно прозаичны - тимлиду для эффективной работы нужно иметь огромное количество "внутренних " знаний о конкретной предметной области, продукте, команде и компании. И порой аккумулировать эти данные приходится годами. Передать их все человеку "с улицы" крайне трудно, для этого в компании должен быть специально поставленный процесс онбординга сотрудников, и далеко не все компании вообще могут себе это позволить, либо не считают это целесообразным. А вот нужда в руководителях команд назревает крайне быстро - практически в любой компании, где больше 10 человек, как минимум один такой специалист необходим.</p>

54 <p>Если команда собирается с нуля, то вариант с повышением кого-то из топовых разработчиков отсутствует, и приходится проводить отбор с рынка. С точки зрения потенциального кандидата - это лучший вариант. Как раз из-за того, что проект еще новый - в нем не накопился техдолг, мало легаси, все люди новые (между ними нет сложившихся неформальных отношений), и можно отлично себя зарекомендовать.</p>

55 <p>В сложившихся компаниях, если не получилось найти подходящего специалиста внутри, и приходится искать его снаружи, нередко можно диагностировать какие-то провалы в процессах, рабочих отношениях или экономической модели. Они еще обильно сдобрены немалым количеством контр-продуктивных практик, которые реализуются по инерции, потому что так принято.</p>

56 <p>И обо всем этом на собеседовании никто будущему руководителю рассказывать не поспешит. Это добавляет ответственности потенциальному тимлиду уже на стадии собеседования - если не задать правильные вопросы и не идентифицировать предстоящие проблемы, то после получения этой должности можно столкнуться и с непреодолимыми проблемами, которые значительно попортят опыт работы и желание продолжать сотрудничество.</p>

57 <h2>Это просто весьма утомительная работа</h2>

58 <p>Как можно догадаться по описанному списку разнообразных проблем, которые так или иначе одним из концов упираются в тимлида, на этой позиции человек сталкивается с очень серьезной нагрузкой. Как справедливо пишет википедия:</p>

59 <blockquote><p>Исследования показывают, что работа руководителя низового звена является напряженной и наполненной разнообразными действиями. Она характеризуется частыми перерывами, переходами от одной задачи к другой. Задачи сами по себе потенциально краткие: в одном исследовании обнаружено, что время, затрачиваемое мастером в среднем на выполнение одного задания равнялось 48 секундам. Временной период для реализации решений, принимаемых мастером, также короткий.</p>

60 </blockquote><p>Для успешного выполнения требований от тимлида требуется, во-первых, держать в голове много мелких деталей о принципах работы продукта и используемых в нем технологий. Во-вторых - умение контролировать одновременно кратко-, средне- и долгосрочные вопросы, регулярно переключаясь между ними. Это в свою очередь влечет очень высокие требования к навыку управлению собственным временем. В относительно успешном продукте у тимлида много открытых вопросов, которые он должен решить. И их всегда больше, чем он успевает обработать. Поэтому важно умение их грамотно приоритизировать и приложить нужные усилия в нужный момент.</p>

61 <p>Гипотетически, вы всегда можете найти крайнего среди своих подчиненных и озадачить его. Однако руководители, систематически решающие проблемы именно таким образом, не пользуются большим уважением ни у коллег, ни у членов команды, и имеют мало шансов продвинуться дальше в управленческой вертикали.</p>

62 <h2>Выводы</h2>

63 <p>Поскольку мы в этой статье сфокусировались на сложностях, с которыми сталкивается тимлид, может сложиться впечатление, что это неблагодарная и чрезмерно тяжелая работа. На самом деле - это соразмерная плата за огромный пласт очень полезного опыта, новые точки личного и профессионального роста, возможность в куда большей степени влиять на продукт. И самое главное, - за возможность решать более сложные и менее типовые задачи, а ведь это один из главных мотиваторов любого инженера и одна из движущих сил, сделавших многих из нас разработчиками.</p>

64 <p>Абсолютно точно не стоит ее бояться, надо лишь здраво оценивать свои возможности и соизмерять их с теми ожиданиями, которые к вам предъявляет эта должность. Кроме того, разумно предположить, что чем выше ответственность, тем выше предполагается за нее и компенсация.</p>

65 <p>Оправдывает ли себя эта ответственность и сопутствующая ей смена условий работы - каждый решает сам. Есть немало других направлений профессионального развития, не включающих в себя менеджерские функции. А может быть вы прочитали это и поняли, что это именно то, чего вы хотите? В таком случае мы можем лишь поддержать подобные устремления и пожелать удачи на этом нелегком пути.</p>