Всем привет, меня зовут Дима, и последние 9 лет я работаю в компании Veeam. Начав простым C# разработчиком, я вырос в тимлида маленькой, но дружной команды из семи человек. Как так получилось, а также о том, что начинается там, где заканчиваются статьи с историями успеха – об этом и многом другом мой рассказ.
В отличие от большинства детей постсоветского времени, мне посчастливилось довольно рано обзавестись собственным компьютером. Достался он мне в подарок от дяди, но был незамедлительно убран в шкаф (за мои плохие оценки) и увидел свет лишь спустя год. Выпиливание лобзиком корабликов, строительство моделей ракет, безуспешные попытки самоубиться, прыгая с крыши одной многоэтажки на другую – всё потеряло смысл, едва я дорвался до чуда инженерной мысли. Бессчётные часы за досовским арканоидом, горы дисков с игрухами и неизвестным софтинами, которые нужно было обязательно установить и пощупать (одной из таких стала кривая Windows NT, после неосторожного взаимодействия с которой я научился ставить ОС). Жемчужиной моей коллекции стал собственноручно написанный батник, который рекурсивно обходил файловую систему, снося всё на своём пути. Переливаясь на солнце, как медный таз, от ощущения собственной крутости, я пришёл к дяде с дискетой и, преисполненный гордости, заявил, что написал самый настоящий вирус. Дядька посмотрел на мои художества, сказал, что работать не будет, и запустил на диске C:\. Глядя на посеревшее дядино лицо, я понял, что просто обязан стать программистом!
К сожалению, на этом моя история успеха вильнула куда-то не туда. Уроки информатики ограничивались освоением Ворда и Экселя и до самого выпуска не приносили сколько-нибудь новых знаний, а на экзамене нас просили угадать название шрифта по наличию подсечек.
Чуть лучше ситуация обстояла с играми. Сталкиваясь с несовершенством игровых механик, мне до жути хотелось их изменить. Нашлись и друзья по интересам, с одним из которых мы до сих пор разрабатываем несколько совместных проектов. Куча часов, проведенных за скриптованием карт в Heroes of Might & Magic IV (да-да, HoMM 3 – one love, но Wake of God тогда ещё не было); последовавший бум Game, RPG и прочих Maker’ов, которые подталкивали творить – и заложили основы понимания условных переходов, циклов и просто базовой логики компьютерных программ.
Но и там я сталкивался с непреодолимым барьером непонимания концепций ключевых слов, фреймворков, ООП и банальным отсутствием знания английского языка.
Кончилась школа, и я остался на распутье с неутоленной жаждой программировать и полнейшим непониманием, с чего начинать. Походив на вечерние курсы в ИТМО, я преисполнился уверенности в собственной ничтожности и пошёл в единственное место, где ещё принимали документы от таких, как я – в техникум геодезии и картографии.
В своё оправдание могу сказать, что девчонки из приемной комиссии заманивали нас к себе, как ни один HR в международную компанию. Рисуя золотые горы, интересные предметы и шикарные переспективы, они сыпали названиями программ, приборов, и не забывали подстраиваться под собеседника – конечно, нам нужны IT’шники, конечно вы научитесь писать плагины под автокад и устроитесь на работу своей мечты!..
В общем-то они не соврали – научился, устроился, вот только всё как-то не благодаря, а вопреки. Три года нас учили чертить тушью, что едва не поставило жирную точку в моей карьере программиста и значительно отбросило назад. Но всё-таки это было шикарное время – куча новых знакомых и связей. Сейчас все они разъехались по миру, и я знаю, к кому мне обратиться, если понадобится помощь от чувака из СБ банка или от директора сети ресторанов.
Нас выпустили в мир. Чуть повзрослевших и поумневших, но с устаревшими на десятилетие знаниями по картографии и отсутствием какого-либо практического опыта. Сидеть на шее у родителей было не комильфо, поэтому не оставалось ничего другого, как двинуть на поклон в компанию, где мы проходили практику. Там моя карьера картографа и закончилась на первой же оцифрованной карте. Пришедшие в ужас редакторы быстренько сплавили меня в местный IT-департамент, где я начал писать макросы для автоматизации всевозможной рутины. “Вышки” у меня тогда не было, контора государственная, и под мою скромную персону выделили отдельную единицу в штатном расписании: техник-картограф технологического отдела. В таком амплуа я и познал дзен.
Если писать макросы я приноровился быстро, то в разрезе освоения программирования это было возвращение к корням. Полностью выпав из этой темы, я забыл то немногое, что освоил, ковыряя игрушки, и оказался лицом к лицу с набором тулов на С++, написанных в соответствии с лучшими практиками опытных собаководов: обложенные ифдефами портянки функций на 1500 строк, которые работают в 2/3 случаях – а почему не работают в оставшихся, не знает и их создатель. На тот момент я знал только то, что есть такой язык программирования, и на нём пишут бородатые дядьки, как мой тогдашний шеф.
Началась эпоха офигительных открытий. Я читал строчку кода, не понимал ничего, разбивал её на токены – лучше не становилось. После чего шёл на популярные тогда форумы с идиотскими вопросами в стиле: «вот здесь написано &&», а здесь просто «&» — в чём разница? Концепция битовых флагов, указателей, указателей на указатели и вообще менеджмент памяти – всё это было в новинку и генерировало нескончаемый поток вопросов, который однажды разбился о фразу, которая стала для меня поворотным моментом: «Чувак, сейчас 2010-ый год! Никто не пишет на С++, попробуй лучше C#!»
Конечно, сейчас это утверждение смотрится смешно и нелепо, но я до сих пор благодарен этому комментатору. Он открыл для меня новый мир, в котором не было магических чисел и AccessViolation. Мир, в котором каждый класс идёт в комплекте с парой страниц документации. Мир, в котором правило Fail Fast! возведено в абсолют, в несколько раз снижая стоимость разработки и поддержки кода. Это был прекрасный мир C#, языка, который помог мне стать программистом.
Обретя понимание происходящего, перестав воспринимать отдельные области программы как чёрный ящик, работающий на волшебном дыме, освоив отладчик и получив понимание, что код может не только работать, но при этом оставаться читабельным и приятным глазу, я переписал весь инструментарий, и за следующий год настрочил сотни килобайт кода, отыгрываясь за голодное детство. Поступил на вечерку в ИТМО и получал неимоверное удовольствие от работы днём, студенческой жизни вечером и кодинга ночью.
Увы, работа на благо картографии закончилась довольно печально. Зарплату задерживали уже полгода, а кушать хотелось. Я принял волевое решение начать поиск работы. Говорят, тогда это было сделать не так просто как сейчас – рынок ещё не успел перегреться, IT-гиганты ещё не заливали всё деньгами, и на собеседовании нужно было выкладываться на 146%… Я этого не ощутил, потому что опубликовав свое резюме на IT-мозгах, уже на следующий день получил приглашение на собеседование в Veeam.
На волне эйфории от собственных успехов шёл я туда, как и полагается всем юным дарованиям, с дурным блеском в глазах, пустой головой и полной уверенностью в своей исключительной шикарности. Во время телефонного звонка сходу выдал, что хочу должность Experienced Developer и не меньше! Хвала HR – минут за 10 она поселила во мне некоторые сомнения, и я согласился рассмотреть вакансию Middle-разработчика, а на последующем интервью я сполна осознал уровень своей некомпетентности. К счастью, это не помешало мне устроиться в компанию, а последующие приступы осознания своего несовершенства я воспринимал как наглядную демонстрацию личного роста и испытывал исключительно положительные эмоции.
Продукты Veeam занимаются простой снаружи и сложной внутри задачей – резервным копированием и репликацией данных. Больше всего в это погружены сисадмины с разнообразным набором серверов, но на должность программиста они приходят не так уж и часто. В то же время вчерашний студент в лучшем случае бэкапил свой диплом в облако да разворачивал виртуалки на VMware Workstation для выполнения лабораторных работ. Поэтому всем, кто приходит на собеседование в мою команду, я говорю – да, на сайте написано, что мы делаем Backup & Replication, но на местах мы решаем проблемы: мы пишем распределенные решения, облачные истории, обвязки вокруг криптографии и механизмов сжатия, хитрые алгоритмы и сетевые протоколы. Не нужно бояться нас из-за незнания предметной области, и главное – не стоит опасаться скуки. У нас весело и интересно, а скучно не бывает никогда!
Но есть и обратная сторона медали – без понимания, какие проблемы бизнеса решает его алгоритм, программист теряет связь с реальным миром, он может принимать неверные технические решения, ломая то, за что клиенты любят наш продукт, и фокусироваться на незначительных деталях, упуская из виду важные проблемы. Поэтому одной из задач тимлида на период прохождения новым сотрудником испытательного срока является погружение его в процесс разработки фичей, имеющих значение для компании и её клиентов. Прошедший этот этап сотрудник пообщается с PM’ами, примет участие в обсуждении концептов и архитектуры решения, получит понимание, что всё это время он пилил небольшой, но важный кусочек продукта, а не просто сферического коня в вакууме.
Возникает вопрос: ну и как тогда ввести новичка в монументальный проект с 10+ летней историей? Для себя я выработал такой алгоритм:
На пальцах и очень верхнеуровнево объяснить, что из себя в целом представляет продукт. Как что хранится, куда пишется, что с чем связывается, и так далее. После этого этапа обычно остаётся пара листочков, исписанных схемами и полное непонимание происходящего в глазах.
Затем надо накатить в лабе наш продукт, который неплохо бы собрать из исходников, и совершить пару самых элементарных операций. Например, забекапить одну машину и продебажить этот процесс. Здесь в глазах появляются первые искорки понимания.
Дать человеку небольшую задачку, полезную для бизнеса, на которой он сможет себя проявить. Здесь мы уже можем оценить человека в боевых условиях и понять, что он из себя представляет.
В моём случае такой задачей стал набор фичей, которые нужно было прикрутить к утилите для валидации бэкапа. По сути, меня выдали в помощь другому разработчику, который уже написал какое-то решение, и оставалось только допиливать отдельные фичи вроде сбора и вывода статистики. И вот тут со мной и случился тот самый культурный шок: мне пришлось изучить под сотню разных классов, которые как-то между собой взаимодействовали. Под слоем которых и скрывался один единственный метод, запускающий валидацию. Это стало серьёзным испытанием для моего неокрепшего сознания. Так я и познакомился с суровыми буднями Enterprise-разработки. Хотелось убежать, но трудовая уже была надёжно спрятана в сейфе отдела кадров.
В моём случае всё получилось довольно органично. Я успешно решал свои задачи, находил наилучшее решение проблем, делился экспертизой с коллегами, помогал в раскуре сложных кейсов. Доверие ко мне росло, с ним ширилась и зона ответственности. В отсутствие шефа, а затем и на постоянной основе я смотрел тестовые задания, помогал новичкам вкатиться в команду, выступал ментором, ставил задачи и контролировал их выполнение. Поэтому к очередному performance review нам оставалось лишь закрепить новую должность официально.
Благодаря такому неспешному погружению в управление я успел проникнуться новым направлением и понял, что мне нравится этот вектор развития. А у моего шефа не осталось сомнений в правильности выбора.
Команда – это не просто слаженный механизм, который переваривает задачи и выдаёт решения. Это экосистема, суммарная производительность которой больше, чем производительность каждого участника в отдельности.
Хорошо сплочённая команда даст не просто пару лишних рук, которые помогут разгрести бэклог. Это мощный инструмент, который позволит повысить техническую экспертизу каждого участника, выработает общие ценности, бест практисы, и будет транслировать их в окружающий мир.
Но ничто не даётся бесплатно. Тимлид берёт на себя ответственность за команду, решения, которые она принимает, и задачи, которые она выполняет. Он ведёт её за собой, направляет развитие, поддерживает благоприятный климат в коллективе, вникает в проблемы каждого участника, помогая ему раскрыть потенциал. И эта работа не заканчивается никогда. Даже если всё работает как часы, и ты можешь выдохнуть, оглядеться по сторонам и найти для себя новые цели, новые вызовы, нельзя забывать о команде, которую нужно продолжать мотивировать на дальнейшее развитие и поддерживать в людях заинтересованность в том, чем они занимаются годами.
В таком режиме ты неминуемо начинаешь отставать в технологическом развитии. Пройдёт несколько лет, и ты в ужасе обнаружишь, что уже не помнишь всю кодовую базу продукта наизусть. Что ты пропускаешь конференции технической направленности, предпочитая развитие управленческих навыков. А вчерашний студент может знать лучше подноготную очередной версии фреймворка, чем ты, который работал с ним уже десяток лет. Но если ты любишь писать код, ты продолжишь его писать. На работе, дома, в рамках пет-проекта, по выходным, как-то ещё. Поэтому смена профиля вовсе не обязательно поставит крест на программировании. При этом ты продолжишь работать с кодовой базой продукта, учить студентов, вводить в проект новых сотрудников и пропускать через себя поток гениальных и не очень идей молодых специалистов, которые позволят не растерять форму. Главное – не замыкаться в себе, не уходить в глубокий консерватизм и прислушиваться к окружающим – среди них полно умных людей, которые знают, как надо, и могут тебя приятно удивить. Главное – уметь слушать их, задавать вопросы и помнить, что каждый стремится к чему-то хорошему. И на этой почве любую идею можно свести к общему знаменателю и построить доверительные отношения между людьми. И тогда вчерашний джун впитает мудрость тимлида, а тимлид узнает, как при помощи нового фреймворка, толики ML и пары строк кода можно оптимизировать работу отдела.
Чтобы не скатываться в банальные советы про чтение книжки о выпасе котов (хотя книжка отличная, тут без вопросов), я расскажу об органичном развитии. Когда-то давно я с товарищем занимался тем, что сейчас называется краудсорсингом. Мы писали моды для игр, в разработке которых могло участвовать по несколько десятков человек. И главная особенность этих коллективов в том, что все работы ведутся исключительно на голом энтузиазме участников. То есть они работают даже не за еду, а за идею в чистом виде. И как и в любом коллективе, у нас возникали конфликты, вот только здесь никак нельзя было мотивировать людей классическими способами с деньгами и прочими материальными плюшками. Правильнее даже будет сказать так — поскольку там коллективы состояли из совершенно рандомных людей, конфликты возникали с утроенной силой. Что можно в такой ситуации делать? Только выстраивать прозрачную и открытую коммуникацию. Задавать вопросы, выяснять, что хотел донести каждый, и учить людей договариваться между собой, попутно не забывая вдохновлять их на новые подвиги. Приходилось рассматривать вагон и маленькую тележку конфликтных ситуаций и крепко над ними думать. Учиться контролировать эмоции, снижать накал страстей в холиварах, разбираться, чем живёт каждый участник проекта, что его драйвит, а что может стриггерить новый конфликт. И вновь и вновь говорить с людьми, нередко останавливая работу над проектом на целый день, чтобы каждый участник смог увидеть картину мира коллеги и понять, за какое добро тот сражается. Вот такая вот школа тимлидской жизни. Было весело и очень полезно. Поэтому практика – наше всё.
Если ваша компания предлагает вам проходить соответствующие тренинги, никогда не пренебрегайте этой возможностью. Даже если на первый взгляд кажется, что вам там рассказывают азбучные истины – когда ты слышишь их со стороны, они гораздо лучше укладываются в голове. Например, многим очевидно, что договоренности нужно фиксировать, чтобы не было испорченного телефона, подмены целей, накидываний на вентилятор и т.д. Но потом ты идёшь на конференцию и наблюдаешь, как 32 человека последовательно наступают на эти грабли и в течение 30 минут безрезультатно пытаются выбрать руководителя, вновь и вновь возвращаются к уже отброшенным вариантам, и лишь за пару минут до дедлайна задаются вопросом – а что же мы всё-таки должны были сделать? И таких примеров масса: наш мозг склонен к когнитивным искажениям, и пока его явно не ткнёшь в проблему, он будет старательно её не замечать.
Нет возможности проходить тренинги – читайте книжки. Главное, не забывайте пропускать всю информацию через призму критического восприятия. То, что взлетело в одной компании, не обязательно взлетит и у вас.
В тот момент, когда ты становишься тимлидом, на тебя возлагается огромная ответственность. Но что произойдёт, если тебя внезапно не станет? Не будем о самом грустном, но ты банально можешь заболеть, уйти в отпуск, отправиться на конференцию или в командировку. Наконец, уволиться и пойти разводить павлинов и сажать пальмы в Сибири. Что станет в этом случае с твоей командой? Кто поведет её в светлое будущее вместо тебя? И нет, едва ли это твой текущий начальник, потому что он и так загружен, а если на него свалится ещё и твоя растущая команда, то он окончательно перестанет вывозить.
Поэтому свой путь в новой должности стоит начать с наблюдения за своей новой командой в поисках человека, который может стать надёжной опорой и сумеет подменить в любой стиуации. Человека, которому ты будешь доверять не меньше, чем себе. И если кто-то подобный на горизонте есть – стоит сконцентрироваться на его развитии. Просто посмотри назад, и вспомни, как начинался твой путь.
Если команда уже достигла пика своего развития, не требует дальнейшего усиления новыми людьми, и нужно просто освободить личные ресурсы, то можно медленно отойти в сторонку, позволив заместителю самому заниматься командой. К этому моменту он уже наверняка станет негласным лидером, и проблем с принятием его руководства возникнуть не должно.
Если же команда только развивается и активно захватывает всё новые области ответственности, стоит набирать людей не в своё прямое подчинение, а делегировать это наиболее перспективным ребятам, которые хотят развиваться в лидов. Это позволит им испытать свои силы, плавно вкатиться в процесс управления и понемногу стать во главе подкоманд. В дальнейшем их можно отпустить в свободное плаванье или продолжить выстраивать иерархическую структуру.
Я стою во главе как раз такой динамично развивающейся и растущей во все стороны команды. Это здорово! Но есть и обратная сторона – поскольку молодым лидам будет тяжело работать с матёрыми сеньорами, у которых по любому вопросу уже есть свое мнение, нанимать им в помощь приходится молодых специалистов. А это требует огромных усилий и на этапе онбординга, и в дальнейшем развитии. Такие команды имеют отличный потенциал в долгосрочной перспективе, но здесь и сейчас ты будешь отставать от своих коллег, которые набирают топовых разработчиков и решают одну проблему за другой. Что выбирать – решать тебе.
Как же понять, что ты всё делаешь правильно? Очень просто – если убрать из команды тимлида, и ничего не изменится, значит, тимлид выполнил свою задачу на отлично. Чем более автономна команда, чем меньше нужно уделять ей времени, тем лучше. Главное – чётко понимать, где проходит грань между делегированием (ответственность остаётся на тебе) и спихиванием задач. Команда должна не просто действовать автономно, но продолжать идти заданным курсом, нести в мир заложенные ценности и продолжать развиваться. Просто без твоего участия.
В заключение хочу сказать: помните, что Team Leader – это не просто руководитель, это прежде всего лидер. Он ведёт за собой и своим примером показывает, как нужно работать, а как делать не стоит. Если тимлид отвечает на письма в два часа ночи, скоро и вся команда начнёт это делать. Если тимлид боится брать на себя ответственность, то и команда будет всеми силами её избегать. Будьте образцом для подражания, и команда станет отражением ваших идеалов. Помните, не бывает хороших тимлидов, которым дали плохую команду.
Моя история успеха
В отличие от большинства детей постсоветского времени, мне посчастливилось довольно рано обзавестись собственным компьютером. Достался он мне в подарок от дяди, но был незамедлительно убран в шкаф (за мои плохие оценки) и увидел свет лишь спустя год. Выпиливание лобзиком корабликов, строительство моделей ракет, безуспешные попытки самоубиться, прыгая с крыши одной многоэтажки на другую – всё потеряло смысл, едва я дорвался до чуда инженерной мысли. Бессчётные часы за досовским арканоидом, горы дисков с игрухами и неизвестным софтинами, которые нужно было обязательно установить и пощупать (одной из таких стала кривая Windows NT, после неосторожного взаимодействия с которой я научился ставить ОС). Жемчужиной моей коллекции стал собственноручно написанный батник, который рекурсивно обходил файловую систему, снося всё на своём пути. Переливаясь на солнце, как медный таз, от ощущения собственной крутости, я пришёл к дяде с дискетой и, преисполненный гордости, заявил, что написал самый настоящий вирус. Дядька посмотрел на мои художества, сказал, что работать не будет, и запустил на диске C:\. Глядя на посеревшее дядино лицо, я понял, что просто обязан стать программистом!
К сожалению, на этом моя история успеха вильнула куда-то не туда. Уроки информатики ограничивались освоением Ворда и Экселя и до самого выпуска не приносили сколько-нибудь новых знаний, а на экзамене нас просили угадать название шрифта по наличию подсечек.
Чуть лучше ситуация обстояла с играми. Сталкиваясь с несовершенством игровых механик, мне до жути хотелось их изменить. Нашлись и друзья по интересам, с одним из которых мы до сих пор разрабатываем несколько совместных проектов. Куча часов, проведенных за скриптованием карт в Heroes of Might & Magic IV (да-да, HoMM 3 – one love, но Wake of God тогда ещё не было); последовавший бум Game, RPG и прочих Maker’ов, которые подталкивали творить – и заложили основы понимания условных переходов, циклов и просто базовой логики компьютерных программ.
Но и там я сталкивался с непреодолимым барьером непонимания концепций ключевых слов, фреймворков, ООП и банальным отсутствием знания английского языка.
Кончилась школа, и я остался на распутье с неутоленной жаждой программировать и полнейшим непониманием, с чего начинать. Походив на вечерние курсы в ИТМО, я преисполнился уверенности в собственной ничтожности и пошёл в единственное место, где ещё принимали документы от таких, как я – в техникум геодезии и картографии.
В своё оправдание могу сказать, что девчонки из приемной комиссии заманивали нас к себе, как ни один HR в международную компанию. Рисуя золотые горы, интересные предметы и шикарные переспективы, они сыпали названиями программ, приборов, и не забывали подстраиваться под собеседника – конечно, нам нужны IT’шники, конечно вы научитесь писать плагины под автокад и устроитесь на работу своей мечты!..
В общем-то они не соврали – научился, устроился, вот только всё как-то не благодаря, а вопреки. Три года нас учили чертить тушью, что едва не поставило жирную точку в моей карьере программиста и значительно отбросило назад. Но всё-таки это было шикарное время – куча новых знакомых и связей. Сейчас все они разъехались по миру, и я знаю, к кому мне обратиться, если понадобится помощь от чувака из СБ банка или от директора сети ресторанов.
Нас выпустили в мир. Чуть повзрослевших и поумневших, но с устаревшими на десятилетие знаниями по картографии и отсутствием какого-либо практического опыта. Сидеть на шее у родителей было не комильфо, поэтому не оставалось ничего другого, как двинуть на поклон в компанию, где мы проходили практику. Там моя карьера картографа и закончилась на первой же оцифрованной карте. Пришедшие в ужас редакторы быстренько сплавили меня в местный IT-департамент, где я начал писать макросы для автоматизации всевозможной рутины. “Вышки” у меня тогда не было, контора государственная, и под мою скромную персону выделили отдельную единицу в штатном расписании: техник-картограф технологического отдела. В таком амплуа я и познал дзен.
Если писать макросы я приноровился быстро, то в разрезе освоения программирования это было возвращение к корням. Полностью выпав из этой темы, я забыл то немногое, что освоил, ковыряя игрушки, и оказался лицом к лицу с набором тулов на С++, написанных в соответствии с лучшими практиками опытных собаководов: обложенные ифдефами портянки функций на 1500 строк, которые работают в 2/3 случаях – а почему не работают в оставшихся, не знает и их создатель. На тот момент я знал только то, что есть такой язык программирования, и на нём пишут бородатые дядьки, как мой тогдашний шеф.
Началась эпоха офигительных открытий. Я читал строчку кода, не понимал ничего, разбивал её на токены – лучше не становилось. После чего шёл на популярные тогда форумы с идиотскими вопросами в стиле: «вот здесь написано &&», а здесь просто «&» — в чём разница? Концепция битовых флагов, указателей, указателей на указатели и вообще менеджмент памяти – всё это было в новинку и генерировало нескончаемый поток вопросов, который однажды разбился о фразу, которая стала для меня поворотным моментом: «Чувак, сейчас 2010-ый год! Никто не пишет на С++, попробуй лучше C#!»
Конечно, сейчас это утверждение смотрится смешно и нелепо, но я до сих пор благодарен этому комментатору. Он открыл для меня новый мир, в котором не было магических чисел и AccessViolation. Мир, в котором каждый класс идёт в комплекте с парой страниц документации. Мир, в котором правило Fail Fast! возведено в абсолют, в несколько раз снижая стоимость разработки и поддержки кода. Это был прекрасный мир C#, языка, который помог мне стать программистом.
Обретя понимание происходящего, перестав воспринимать отдельные области программы как чёрный ящик, работающий на волшебном дыме, освоив отладчик и получив понимание, что код может не только работать, но при этом оставаться читабельным и приятным глазу, я переписал весь инструментарий, и за следующий год настрочил сотни килобайт кода, отыгрываясь за голодное детство. Поступил на вечерку в ИТМО и получал неимоверное удовольствие от работы днём, студенческой жизни вечером и кодинга ночью.
Увы, работа на благо картографии закончилась довольно печально. Зарплату задерживали уже полгода, а кушать хотелось. Я принял волевое решение начать поиск работы. Говорят, тогда это было сделать не так просто как сейчас – рынок ещё не успел перегреться, IT-гиганты ещё не заливали всё деньгами, и на собеседовании нужно было выкладываться на 146%… Я этого не ощутил, потому что опубликовав свое резюме на IT-мозгах, уже на следующий день получил приглашение на собеседование в Veeam.
На волне эйфории от собственных успехов шёл я туда, как и полагается всем юным дарованиям, с дурным блеском в глазах, пустой головой и полной уверенностью в своей исключительной шикарности. Во время телефонного звонка сходу выдал, что хочу должность Experienced Developer и не меньше! Хвала HR – минут за 10 она поселила во мне некоторые сомнения, и я согласился рассмотреть вакансию Middle-разработчика, а на последующем интервью я сполна осознал уровень своей некомпетентности. К счастью, это не помешало мне устроиться в компанию, а последующие приступы осознания своего несовершенства я воспринимал как наглядную демонстрацию личного роста и испытывал исключительно положительные эмоции.
Первые дни в большой компании
Продукты Veeam занимаются простой снаружи и сложной внутри задачей – резервным копированием и репликацией данных. Больше всего в это погружены сисадмины с разнообразным набором серверов, но на должность программиста они приходят не так уж и часто. В то же время вчерашний студент в лучшем случае бэкапил свой диплом в облако да разворачивал виртуалки на VMware Workstation для выполнения лабораторных работ. Поэтому всем, кто приходит на собеседование в мою команду, я говорю – да, на сайте написано, что мы делаем Backup & Replication, но на местах мы решаем проблемы: мы пишем распределенные решения, облачные истории, обвязки вокруг криптографии и механизмов сжатия, хитрые алгоритмы и сетевые протоколы. Не нужно бояться нас из-за незнания предметной области, и главное – не стоит опасаться скуки. У нас весело и интересно, а скучно не бывает никогда!
Но есть и обратная сторона медали – без понимания, какие проблемы бизнеса решает его алгоритм, программист теряет связь с реальным миром, он может принимать неверные технические решения, ломая то, за что клиенты любят наш продукт, и фокусироваться на незначительных деталях, упуская из виду важные проблемы. Поэтому одной из задач тимлида на период прохождения новым сотрудником испытательного срока является погружение его в процесс разработки фичей, имеющих значение для компании и её клиентов. Прошедший этот этап сотрудник пообщается с PM’ами, примет участие в обсуждении концептов и архитектуры решения, получит понимание, что всё это время он пилил небольшой, но важный кусочек продукта, а не просто сферического коня в вакууме.
Возникает вопрос: ну и как тогда ввести новичка в монументальный проект с 10+ летней историей? Для себя я выработал такой алгоритм:
На пальцах и очень верхнеуровнево объяснить, что из себя в целом представляет продукт. Как что хранится, куда пишется, что с чем связывается, и так далее. После этого этапа обычно остаётся пара листочков, исписанных схемами и полное непонимание происходящего в глазах.
Затем надо накатить в лабе наш продукт, который неплохо бы собрать из исходников, и совершить пару самых элементарных операций. Например, забекапить одну машину и продебажить этот процесс. Здесь в глазах появляются первые искорки понимания.
Дать человеку небольшую задачку, полезную для бизнеса, на которой он сможет себя проявить. Здесь мы уже можем оценить человека в боевых условиях и понять, что он из себя представляет.
В моём случае такой задачей стал набор фичей, которые нужно было прикрутить к утилите для валидации бэкапа. По сути, меня выдали в помощь другому разработчику, который уже написал какое-то решение, и оставалось только допиливать отдельные фичи вроде сбора и вывода статистики. И вот тут со мной и случился тот самый культурный шок: мне пришлось изучить под сотню разных классов, которые как-то между собой взаимодействовали. Под слоем которых и скрывался один единственный метод, запускающий валидацию. Это стало серьёзным испытанием для моего неокрепшего сознания. Так я и познакомился с суровыми буднями Enterprise-разработки. Хотелось убежать, но трудовая уже была надёжно спрятана в сейфе отдела кадров.
Как я стал тимлидом
В моём случае всё получилось довольно органично. Я успешно решал свои задачи, находил наилучшее решение проблем, делился экспертизой с коллегами, помогал в раскуре сложных кейсов. Доверие ко мне росло, с ним ширилась и зона ответственности. В отсутствие шефа, а затем и на постоянной основе я смотрел тестовые задания, помогал новичкам вкатиться в команду, выступал ментором, ставил задачи и контролировал их выполнение. Поэтому к очередному performance review нам оставалось лишь закрепить новую должность официально.
Благодаря такому неспешному погружению в управление я успел проникнуться новым направлением и понял, что мне нравится этот вектор развития. А у моего шефа не осталось сомнений в правильности выбора.
Зачем тимлиду команда
Команда – это не просто слаженный механизм, который переваривает задачи и выдаёт решения. Это экосистема, суммарная производительность которой больше, чем производительность каждого участника в отдельности.
Хорошо сплочённая команда даст не просто пару лишних рук, которые помогут разгрести бэклог. Это мощный инструмент, который позволит повысить техническую экспертизу каждого участника, выработает общие ценности, бест практисы, и будет транслировать их в окружающий мир.
Но ничто не даётся бесплатно. Тимлид берёт на себя ответственность за команду, решения, которые она принимает, и задачи, которые она выполняет. Он ведёт её за собой, направляет развитие, поддерживает благоприятный климат в коллективе, вникает в проблемы каждого участника, помогая ему раскрыть потенциал. И эта работа не заканчивается никогда. Даже если всё работает как часы, и ты можешь выдохнуть, оглядеться по сторонам и найти для себя новые цели, новые вызовы, нельзя забывать о команде, которую нужно продолжать мотивировать на дальнейшее развитие и поддерживать в людях заинтересованность в том, чем они занимаются годами.
В таком режиме ты неминуемо начинаешь отставать в технологическом развитии. Пройдёт несколько лет, и ты в ужасе обнаружишь, что уже не помнишь всю кодовую базу продукта наизусть. Что ты пропускаешь конференции технической направленности, предпочитая развитие управленческих навыков. А вчерашний студент может знать лучше подноготную очередной версии фреймворка, чем ты, который работал с ним уже десяток лет. Но если ты любишь писать код, ты продолжишь его писать. На работе, дома, в рамках пет-проекта, по выходным, как-то ещё. Поэтому смена профиля вовсе не обязательно поставит крест на программировании. При этом ты продолжишь работать с кодовой базой продукта, учить студентов, вводить в проект новых сотрудников и пропускать через себя поток гениальных и не очень идей молодых специалистов, которые позволят не растерять форму. Главное – не замыкаться в себе, не уходить в глубокий консерватизм и прислушиваться к окружающим – среди них полно умных людей, которые знают, как надо, и могут тебя приятно удивить. Главное – уметь слушать их, задавать вопросы и помнить, что каждый стремится к чему-то хорошему. И на этой почве любую идею можно свести к общему знаменателю и построить доверительные отношения между людьми. И тогда вчерашний джун впитает мудрость тимлида, а тимлид узнает, как при помощи нового фреймворка, толики ML и пары строк кода можно оптимизировать работу отдела.
Как научиться управлять людьми
Чтобы не скатываться в банальные советы про чтение книжки о выпасе котов (хотя книжка отличная, тут без вопросов), я расскажу об органичном развитии. Когда-то давно я с товарищем занимался тем, что сейчас называется краудсорсингом. Мы писали моды для игр, в разработке которых могло участвовать по несколько десятков человек. И главная особенность этих коллективов в том, что все работы ведутся исключительно на голом энтузиазме участников. То есть они работают даже не за еду, а за идею в чистом виде. И как и в любом коллективе, у нас возникали конфликты, вот только здесь никак нельзя было мотивировать людей классическими способами с деньгами и прочими материальными плюшками. Правильнее даже будет сказать так — поскольку там коллективы состояли из совершенно рандомных людей, конфликты возникали с утроенной силой. Что можно в такой ситуации делать? Только выстраивать прозрачную и открытую коммуникацию. Задавать вопросы, выяснять, что хотел донести каждый, и учить людей договариваться между собой, попутно не забывая вдохновлять их на новые подвиги. Приходилось рассматривать вагон и маленькую тележку конфликтных ситуаций и крепко над ними думать. Учиться контролировать эмоции, снижать накал страстей в холиварах, разбираться, чем живёт каждый участник проекта, что его драйвит, а что может стриггерить новый конфликт. И вновь и вновь говорить с людьми, нередко останавливая работу над проектом на целый день, чтобы каждый участник смог увидеть картину мира коллеги и понять, за какое добро тот сражается. Вот такая вот школа тимлидской жизни. Было весело и очень полезно. Поэтому практика – наше всё.
Если ваша компания предлагает вам проходить соответствующие тренинги, никогда не пренебрегайте этой возможностью. Даже если на первый взгляд кажется, что вам там рассказывают азбучные истины – когда ты слышишь их со стороны, они гораздо лучше укладываются в голове. Например, многим очевидно, что договоренности нужно фиксировать, чтобы не было испорченного телефона, подмены целей, накидываний на вентилятор и т.д. Но потом ты идёшь на конференцию и наблюдаешь, как 32 человека последовательно наступают на эти грабли и в течение 30 минут безрезультатно пытаются выбрать руководителя, вновь и вновь возвращаются к уже отброшенным вариантам, и лишь за пару минут до дедлайна задаются вопросом – а что же мы всё-таки должны были сделать? И таких примеров масса: наш мозг склонен к когнитивным искажениям, и пока его явно не ткнёшь в проблему, он будет старательно её не замечать.
Нет возможности проходить тренинги – читайте книжки. Главное, не забывайте пропускать всю информацию через призму критического восприятия. То, что взлетело в одной компании, не обязательно взлетит и у вас.
Как растить свою команду, которая вырастет в другую команду
В тот момент, когда ты становишься тимлидом, на тебя возлагается огромная ответственность. Но что произойдёт, если тебя внезапно не станет? Не будем о самом грустном, но ты банально можешь заболеть, уйти в отпуск, отправиться на конференцию или в командировку. Наконец, уволиться и пойти разводить павлинов и сажать пальмы в Сибири. Что станет в этом случае с твоей командой? Кто поведет её в светлое будущее вместо тебя? И нет, едва ли это твой текущий начальник, потому что он и так загружен, а если на него свалится ещё и твоя растущая команда, то он окончательно перестанет вывозить.
Поэтому свой путь в новой должности стоит начать с наблюдения за своей новой командой в поисках человека, который может стать надёжной опорой и сумеет подменить в любой стиуации. Человека, которому ты будешь доверять не меньше, чем себе. И если кто-то подобный на горизонте есть – стоит сконцентрироваться на его развитии. Просто посмотри назад, и вспомни, как начинался твой путь.
Сложнее дело обстоит с подбором людей.
Если команда уже достигла пика своего развития, не требует дальнейшего усиления новыми людьми, и нужно просто освободить личные ресурсы, то можно медленно отойти в сторонку, позволив заместителю самому заниматься командой. К этому моменту он уже наверняка станет негласным лидером, и проблем с принятием его руководства возникнуть не должно.
Если же команда только развивается и активно захватывает всё новые области ответственности, стоит набирать людей не в своё прямое подчинение, а делегировать это наиболее перспективным ребятам, которые хотят развиваться в лидов. Это позволит им испытать свои силы, плавно вкатиться в процесс управления и понемногу стать во главе подкоманд. В дальнейшем их можно отпустить в свободное плаванье или продолжить выстраивать иерархическую структуру.
Я стою во главе как раз такой динамично развивающейся и растущей во все стороны команды. Это здорово! Но есть и обратная сторона – поскольку молодым лидам будет тяжело работать с матёрыми сеньорами, у которых по любому вопросу уже есть свое мнение, нанимать им в помощь приходится молодых специалистов. А это требует огромных усилий и на этапе онбординга, и в дальнейшем развитии. Такие команды имеют отличный потенциал в долгосрочной перспективе, но здесь и сейчас ты будешь отставать от своих коллег, которые набирают топовых разработчиков и решают одну проблему за другой. Что выбирать – решать тебе.
Как же понять, что ты всё делаешь правильно? Очень просто – если убрать из команды тимлида, и ничего не изменится, значит, тимлид выполнил свою задачу на отлично. Чем более автономна команда, чем меньше нужно уделять ей времени, тем лучше. Главное – чётко понимать, где проходит грань между делегированием (ответственность остаётся на тебе) и спихиванием задач. Команда должна не просто действовать автономно, но продолжать идти заданным курсом, нести в мир заложенные ценности и продолжать развиваться. Просто без твоего участия.
В заключение хочу сказать: помните, что Team Leader – это не просто руководитель, это прежде всего лидер. Он ведёт за собой и своим примером показывает, как нужно работать, а как делать не стоит. Если тимлид отвечает на письма в два часа ночи, скоро и вся команда начнёт это делать. Если тимлид боится брать на себя ответственность, то и команда будет всеми силами её избегать. Будьте образцом для подражания, и команда станет отражением ваших идеалов. Помните, не бывает хороших тимлидов, которым дали плохую команду.
