Из программиста в тимлиды — личный опыт

Два года назад я променял должность обычного программиста (хоть и «старшего») на должность тимлида. И вот как раз примерно в годовщину этого события я решил собрать свои мысли и идеи по поводу этой трансформации воедино и написать данную статью.

Сразу обращу внимание многоуважаемого читателя на очевидную и важную вещь — все то, что будет описано в статье, является моим личным мнением и моим личным опытом. Это не означает, что всегда надо делать именно так, что проблемы будут всегда именно такие, что решения надо принимать именно такие и так далее. Это просто мой опыт и мои мысли по поводу него по прошествии пары лет, не более того. В сети существуют сотни похожих по тематике, но совершенно разных по содержанию статей, и как мне кажется, что чем больше их будет — тем лучше, ведь люди, которые пойдут по этому же пути, будут видеть ситуацию с разных сторон, для разных компаний и размеров бизнеса, и им будет чуточку легче ориентироваться в их конкретной ситуации. Так что да, работая над этой статьей, я, разумеется, в первую очередь руководствовался своим ЧСВ, веря что этим текстом спасу множество людей от проблем и чаяний =)

Чтобы у уважаемого читателя сложилась более полная картина, я расскажу немного о себе и своем профессиональном пути.

В IT-индустрии я достаточно давно (по меркам современного IT), больше 10 лет. В юности увлекался программированием, писал всякое на Pascal и Visual Basic (на том, который еще не знавал .NET’а), потом закончил институт по IT-специальности, а пока учился — параллельно работал на своей первой серьезной работе, программировал в одном из московских НИИ. К слову сказать, эта работа отбила у меня любовь к программированию, и следующие несколько лет я занимался совершенно не связанными с IT вещами в абсолютно другой области (но это уже совсем другая история). Однако в какой-то момент я все же решил вернуться в программирование, и вот тогда, пожалуй, и началась моя настоящая работа в IT-индустрии.

Так что же такое, товарищи, дебют и что такое, товарищи, идея? Дебют, товарищи, — это «Quasi una fantasia»…
Я имею в виду, зачем вообще становиться тимлидом? На этот вопрос за меня уже ответил классик: если можете не становиться тимлидом — не остановитесь им. В IT-индустрии бытует мнение, и я не однократно с ним сталкивался, что тимлид — это вершина эволюции разработчика, и все программисты рано или поздно должны дорасти до тимлида. Как вы уже могли догадаться, это мнение ошибочно. Тимлид — это одна из ступеней, до которой может дорасти программист, но только если он этого действительно хочет. Ведь тимлид — это не столько про технологии, сколько про управление. Управление людьми, управление проектами, управление планированием, рисками… Разумеется, тимлид должен быть технически подкован, и подкован достаточно хорошо. Однако, он может и не быть самым скилловым разработчиком в команде. Да-да, вау, срыв покровов! Гораздо важнее чтобы он имел хороший технический кругозор, чувствовал куда дует ветер в индустрии и в целом понимал куда она движется, умел смотреть на проекты и возникающие проблемы с крупна, и, конечно же, умел общаться с людьми и управлять ими. На словах это все звучит довольно просто и тривиально, однако это действительно важные навыки хороших тимлидов.

Вообще, рынок в IT-индустрии на данный момент выглядит так, что для существенного роста по зарплате необходимо искать этот рост на стороне, потому что внутри компании скорее всего вам такой же прибавки никто не даст. Почему так — тема отдельной заметки или даже статьи, сейчас мы на этом останавливаться не будем. И если вам вдруг по какой то причине хочется больше денег, но не хочется менять компанию — рост до тимлида видится неплохой альтернативой. Более того — если в компании открывается должность тимлида, в первую очередь рассматриваются сотрудники этой компании, то есть чаще в тимлида вырастают внутри, а не нанимают извне. Так что, в общем-то, программисту не обязательно становиться тимлидом, можно расти в девелоперских компетенциях, прокачивать хард-скиллы и идти в те компании, где предложат подходящие под выросшие компетенции задачи и, соответственно, зарплату. Более того, на мой взгляд это даже более предпочтительный вариант роста программиста. Хорошие разработчики будут нужны всегда, и тенденции в индустрии показывают, что в будущем будут нужны только больше — уже сейчас на рынке существенная нехватка кадров. Тимлидов же нужно в разы меньше. Так что выбор за вами.

Так почему же я выбрал тимлидство? Так вышло, что на предыдущей работе я, хоть и числился «старшим программистом», выполнял чуть больше обязанностей. Начал заниматься развитием продукта в целом, даже в какой-то момент стал руководить разработчиками, как говорится, «пока тимлид не видит». И именно тогда я понял, что мне нравится этим заниматься, а главное — у меня получается. И вот, когда пришло время менять работу (а оно всегда когда-то да приходит), я решил попробовать поискать в первую очередь вакансии тимлида. И нашел!

Стоит сказать пару слов о вакансии — это была вакансия в не-софтверной и даже не-айтишной компании, которая на тот момент проходила этап взрывного роста, и им были необходимы инструменты и сервисы для цифровизации и управления всем этим ростом. По какой-то причине руководство решило не идти на поклон к аутсорс-подрядчикам, а сформировать свой отдел разработки внутри компании. Вот в него я и попал. Попал я не к самому началу формирования отдела, а уже в существующую небольшую команду из пяти человек. На тот момент ими руководил не программист, да и вообще далекий от разработки софта человек, и это рождало много проблем. Именно поэтому в какой-то момент компания приняла решения нанимать тимлида. То есть, сам того не понимая, я выбрал самый сложный вариант превращения в тимлида — прийти на первую свою работу тимлидом со стороны, да еще и в существующую команду. Сказать, что первые несколько месяцев меня терзал синдром самозванца — это ничего не сказать. Однако, когда моя работа начала приносить ощутимые плоды, синдром самозванца отступил. Вообще, синдром самозванца у новоиспеченного тимлида — это нормально. Даже больше, мне кажется если у вас его вдруг нет — это очень нехороший звоночек.

Первое, что я понял став тимлидом — это то, что кода в моей жизни будет в разы меньше, чем было до этого. К счастью, мне удалось в итоге стать «играющим тренером», то есть я все же продолжил писать код (в том числе чтобы не потерять хард-скиллы), но этого стало в разы меньше.

Второе — что теперь я отвечаю не только за свой код, но и за код всей команды. А так же за всю команду в целом — за все их проблемы, и не только технические. Не могу сказать, что все тимлиды должны решать такие проблемы, но в моей «камерной» команде разработки ими занимаюсь именно я.

Третье — что перед заказчиками краснеть тоже придется именно мне. В моем случае заказчики были внутренними, что несколько облегчало ситуацию, но тем не менее. Ведь если заказчик получил не ту фичу, которую планировал получить, или если она не работает вовсе — это моя проблема, это я что-то не доглядел или не продумал.

Четвертое — нужно верить в команду и уметь делегировать задачи. Необходимо понять сильные и слабые стороны каждого члена команды. Только тогда можно будет эффективно управлять разработкой и даже превратить слабые стороны сотрудников в сильные.

Пятое - нужно быть бро для своей команды. Да, именно так. Не стоит строить слишком высокую стену между собой и своими подчиненными, она не сыграет вам на руку, скорее даже наоборот.

Шестое — сроки планирование есть альфа и омега всея разработки. Важно научиться правильному планированию, а также контролировать сроки выполнения задач, не пускать все на самотек. А еще донести до разработчиков, что очень важно незамедлительно сообщать обо всех возникающих проблемах в решении задач. Лучше скорректировать сроки заранее, чем за день до сдачи узнать, что у нас есть серьезная проблема, которую разработчик надеялся решить, но перед сдачей проекта вдруг понял, что не может.

Седьмое — поддерживать контакты с бывшими коллегами. Может показаться, что это странный пункт, но я попробую объяснить что я имею в виду. Будучи программистом, я поработал во многих компаниях и общался со многими коллегами-программистами. Уже тогда я примерно представлял их плюсы и минусы, как в хард-скиллах, так и в софт-скиллах, и когда возникла необходимость брать в команду нового разработчика — я прошерстил старые контакты и нашел отличного кандидата.

А вывод предлагается сделать самому уважаемому читателю. Стоит ли менять уютное кресло программиста на кресло тимлида? Да. Или нет. Тут каждый должен решить для себя сам. Но если вы выберете вариант «да», то скучно вам точно не будет! В конце концов, если не понравится — всегда можно вернуться писать код. Главное не забывайте поддерживать свои хард-скиллы на должном уровне!

P.S. в комментариях приглашаю обсудить тематику, проблематику, покидать в меня тухлыми помидорами и попостить смешные картинки — в конце концов мы же на vc!