Всем привет! Меня зовут Артур Дементьев, я бы хотел поделиться личным опытом и написать несколько статей о том, что из себя представляет менеджмент в IT. А также рассказать о том, на какие грабли наступал и каких ошибок можно было избежать. Все статьи я буду писать, основываясь на своём опыте работы в разных IT-компаниях, в которых я начинал как Team Leader (TL) команды из нескольких человек. В одной из них с нуля вырастил маленький отдел в большую IT-структуру и дорос до CTO.
Проблемы есть во многих компаниях, часто люди допускают ошибки. Именно общение с ними сподвигло меня на написание статьи. В ближайшем времени, я постараюсь продолжить публикации. Надеюсь, они будут полезны TL, CTO, руководителям департаментов или тем, кто только собирается ими стать. А начну я с рассказа о том, что такое быть Team Leader, это будет взгляд изнутри.
Тут сразу стоит сделать отступление. Есть разные компании:
- крупные, где обычно IT — основной профиль деятельности. В иерархии есть CTO, Tech Leader, Team Leader, Architects, Project Manager, Analyst. В таких условиях TL возможно не выполняет некоторых функций, которые я буду описывать ниже;
- бизнесы, где лишь часть компании завязана на IT. Там структура в половину проще первого варианта;
- небольшие фирмы с маленьким IT-отделом из нескольких человек (в моём случае нас было трое). Там просто не на кого переложить все обязанности. Иногда стоит задача вырастить такую контору в компанию из первого пункта списка.
Таким образом, объём и спектр обязанностей TL во многом зависит от размера компании или IT-отдела. Чем крупнее компания и сложнее структура IT в ней, тем меньше обязанностей у TL.
Как становятся Team Leader
Есть два стандартных пути к позиции TL:
- Карьерное развитие программиста на текущем месте работы. Например, когда вы проявляете много инициативы, усердно работаете, вы ответственный, показываете, что у вас есть лидерские качества и т.д. Или вас переводят на освободившееся место, когда по каким-то причинам не хотят приглашать человека со стороны. В этом случае смотрят на заслуги и нередко просто выбирают самого сильного технического специалиста. То есть вас туда выносит течение, а не стремление.
- Вы меняете работу и приходите в новую компанию на место TL. Так бывает, когда у специалиста за плечами много лет опыта и желания развиваться дальше, но рост в существующей компании по каким-то причинам невозможен и сложен. В итоге вы находите компанию, в которой считают, что вы справитесь.
Какой бы путь вас ни привёл к новой должности, но теперь вы будете меньше кодить и управлять людьми.
Перемены в деятельности
Итак, что нового появится в вашей жизни с того момента, как вы превратились из разработчика в TL? Несомненно, вы будете больше участвовать в обсуждениях и присутствовать на совещаниях. Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам. Также придётся больше заниматься code review. Возможно на вас упадут договора и выставления счетов в бухгалтерию. Вроде бы жизнь удалась, и вы добились цели.
Но эйфория проходит довольно быстро, и вы практически начинаете гореть. Происходит примерно следующее: поток задач нескончаем, их надо решать или делегировать, следить, что пишет команда. Надоедливые менеджеры всё время что-то хотят и постоянно зовут на совещания. «Им заняться что ли больше нечем?» — думаете вы. Начальство же жмёт со сроками, а из команды внезапно ушёл человек, и искать замену вам. Ещё и жена звонит. В общем, вы становитесь раздражительным и близки к перегоранию. В таком режиме реально прожить максимум год.
Как выжить в таком аду? Как остальные справляются? Основная проблема в выходе из зоны комфорта. Вы в новом мире, старые правила не действуют. Конечно, выход есть, но найти надо его надо самому, в каком-то смысле сломать себя и осознать кое-что новое.
Что надо понять
Есть несколько вещей, которые надо осознать. И чем раньше вы это сделаете, тем лучше и легче вам станет жить.
- Вам платят деньги не за то, что вы пишите код. Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше. Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.
- Теперь ваши коллеги пишут код лучше вас. Пройдёт полгода-год, и отсутствие практики скажется на ваших способностях. Ведь они это делают практически всё рабочее время, а вы от случая к случаю или дома по вечерам.
- Перестаньте людей равнять на себя. Человек так устроен, что думает, что лучше него решить задачу никто не сможет. Во-первых, это не всегда так, а во-вторых, если вы будете тратить время на решение всех задач, потому что думаете, что люди не справятся, это уже не TL. Доверяйте людям.
- Ваши главные показатели эффективности — качество всего проекта и время разработки. Здесь, пожалуй, главную роль играют ваши навыки коммуникабельности. Что-то надо делать качественно и долго, а иной раз целесообразнее быстрое решение. Сложность состоит в том, что вы должны донести это до программиста и убедить его сделать, как нужно в этот момент. А не через 2 дня обнаружить, что он только на середине, а готовое решение нужно сейчас.
- Мотивируйте людей. Придумайте систему мотиваций, чтобы всем хотелось лучше работать. Выдать премии, если не было аврала? Нет, это ерунда. Внедряйте метрики, собирайте статистику, оценивайте работу людей. Также следите за профессиональным ростом сотрудников, кто как развивается. Всегда держите руку на пульсе.
- Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.
- Вы отвечаете за весь проект. Если ваш сервис вдруг упал надолго или его невозможно восстановить, потому что нет бэкапов, перед руководством всегда будете виноваты вы. Работоспособность проекта в техническом плане — ваша обязанность.
- Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.
- Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.
- Вы должны уметь подменять любого члена команды. Если кто-то заболел, ушёл в отпуск или уволился, и процесс разработки остановился, вся ответственность ложится на вас. Будьте готовы к этому всегда.
- Психологический аспект. Вам необходимо общаться с командой и понимать людей, знать, какие у них могут быть проблемы, и даже помогать решать их. Большая часть программистов — интроверты, вы должны пытаться выяснять, что их не устраивает или мешает на работе. Конечно, большинство и не скажет этого, вам надо научиться это понимать. Но главное не перегибать палку и не становиться психологом вместо начальника, а то это плохо кончается.
Одни минусы. Есть ли плюсы?
Да! И их намного больше минусов. Теперь у вас есть ресурсы, которыми вы управляете. А значит у вас больше средств для достижения результата, то есть решения задач бизнеса. Именно этого он от вас и ждёт.
Я бы сделал сравнение с футбольной командой. Вы как молодой тренер команды, у каждого игрока есть свои сильные и слабые стороны. Если вы будете управлять ими без учёта особенностей каждого, то вряд ли что-то сможете выиграть. Но став настоящим лидером команды, вы должны суметь превратить слабые стороны ваших коллег в сильные ради победы.
Вы можете нанимать не очень опытных людей, но за полгода превращать их в крутых специалистов, которые будут тянуть проект вверх. Помните, что у вас в арсенале есть крутые подходы, например, Scrum или Kanban, которые могут обратить мучительную разработку в хорошо отлаженный процесс для всех его участников.
Также вам открывается огромное поле для экспериментов. У вас появляются ресурсы для поиска и проб новых решений. Это надо делать обязательно, что-то сработает и принесёт успех. Ищите пути, которые будут полезны и команде, и бизнесу. Серебряной пули нет, вам придётся найти своё решение, которое будет работать в конкретных условиях.
Используйте опыт и стройте эффективные системы отбора сотрудников. Также мотивируйте и развивайте команду. И не забывайте о развитии себя: читайте книги, слушайте лекции, ходите на конференции. В конце концов просто общайтесь с людьми и делитесь опытом. В итоге вы построите сильнейшую dream team.
Если ещё не поняли, то со временем осознаете, что самый важный ресурс — это люди. Оставайтесь с ними коллегами, а не начальником и подчинёнными. Будьте единым механизмом, помогайте им, а они будут помогать вам.
Team Leader — это не суперпрограммист, это лидер, который может из любых ресурсов, несмотря ни на что, собрать крутую команду и принести прибыль компании. Вот чем эта работа по-настоящему классная.
Лично для меня высшая похвала, когда приходят люди и говорят: «Ни фига себе какой вы сервис запилили! Ещё и с такой маленькой командой!». После этого ты понимаешь, что всё было не зря. И это даёт сил делать проект ещё лучше. Так сказать, выиграть с ребятами свой чемпионат.
Для тех, кто уже завтра идёт на собеседование
Стоит рассказать и о вакансиях на позицию TL. Как я и писал выше, компании бывают разные, в них разные задачи. На собеседовании попытайтесь понять, кто всё-таки нужен работодателю, чтобы ваши ожидания совпали с реальностью. Особенно смешно, когда в компании нет чёткой иерархии, и всё должно висеть на одном человеке. Обычно в их вакансиях есть фраза: «Придётся программировать 70–80% времени. Я бы советовал избегать таких предложений. Либо на вас хотят сэкономить, либо руководство вообще не понимает зачем им нужен TL. Конечно, каждый случай индивидуален, но всё же есть грани разумного. В конечном итоге человек перегорит и уйдёт, так как жить в стрессе всё время нельзя.
Подходите к выбору места с пониманием того, что хотите получить. Помните, что собеседование проводят не только с вами, но и вы с компанией. Не стесняйтесь и задавайте вопросы, выясняйте всё. Лучше узнать всё заранее, чем потом оказаться в бездне. Можно даже попросить познакомиться с командой, послушать, что говорит ваш будущий коллектив. Цена ошибки высока: неправильное место может отбить всю охоту развиваться дальше и не даст попасть в этот удивительный мир.
Выводы
Выбор стать TL должен быть осознанным решением, а не просто, потому что вам надоело писать код или хотите зарплату повыше. TL — это первая ступенька в IT-менеджменте. На этом этапе можно понять, нравится вам это или нет. И если нет, то всегда можно вернуться в разработчики. Но учтите, если вы долго проработаете TL, то уйти назад может быть сложно. TL не так много пишет код, мир вместе с технологиями сильно меняется, опыт теряется. Может получиться, что вы вернётесь назад, и придётся долго навёрстывать упущенное.
Безусловно это очень интересная работа. Вам придётся сломать своё и начать думать по-новому. И, конечно, покинуть зону комфорта. Но зато вы получите бесценный опыт управления, сможете строить команды и добиваться результатов для компании.
Всё описанное выше приходит с опытом. Учебники и курсы не научат вас быть TL. Но зато смогут помочь обойти немалое количество граблей.
P.S.: Спасибо, что уделили время! Прошу строго не судить, это моя первая статья на хабре. Надеюсь, она окажется кому-то полезной. Я постарался передать свой личный опыт. Буду признателен за любые мнения. Но это лишь начало, дальше я хочу углубится в детали процессов разработки и управления командой и рассказать, как я их выстраивал.
Автор: tyronead
