Одну из сессий конференции YaTalks мы посвятим росту разработчиков. Это будет разговор между представителями разных фирм — мы пригласили CTO онлайн-кинотеатра ivi Евгения eross Россинского, технического директора mos.ru Романа romas1982 Ивлиева и Германа Наркайтиса — директора по инжинирингу компании Apstra. От нас будут участвовать руководители разных команд в поисковом портале: Ольга Мегорская и (в роли модератора) Андрей yafinder Плахов.
Мы подумали, что перед дискуссией стоит «синхронизироваться» в терминах. Все хотя бы примерно представляют, что такое вертикальный рост. С горизонтальным всё сложнее: хорошие примеры выросших горизонтально людей не так видны из-за пределов компании. В чём состоит их работа? Они пишут код или только занимаются код-ревью, составлением методологий и т. д.? А возвращаясь к вертикальному росту — какие главные проблемы встают перед (будущим) тимлидом? Мы задали эти вопросы участникам дискуссии и сегодня публикуем их ответы на Хабре. Тех разработчиков, кто выбрал горизонтальную ветку развития, будем называть экспертами — имея в виду, что они управляют не людьми, а технологиями.
Евгений Россинский, CTO ivi
Небезразличные разработчики
Помимо вертикального роста, по административной линии, разработчики могут расти горизонтально — в технологических экспертов. Тогда важнее хард-скиллы. Это очень сильные, небезразличные разработчики, которые развивают концепцию архитектуры продукта. Им не требуется менеджмент — они самостоятельно находят «дырки» в продуктах и закрывают их. Если надо, они сами пишут код, собирают и разбирают команды. На таких людях у нас держится большая часть архитектурных решений. В нашей компании 26 команд, в каждой из них примерно по 10 человек, из них 2-3 эксперта. Более того, иногда мы создаём команды только из таких суперзвёзд. Рост эксперта зависит от уровня и количества проектов, которые он курирует.
Когда разработчик понимает, что растёт «не туда», главное — раскрыть потребность в переменах перед командой и проработать план миграции. Раз в квартал мы проводим встречи, на которых каждый член команды наедине с тимлидом или scrum-мастером обсуждают, куда ему расти дальше. Также у нас есть гильдия scrum-мастеров и специальные чатики с обсуждениями подобных тем. Затем мы ищем, куда можно пристроить человека, и составляем roadmap с milestones, которые ему следует пройти. Если человек мечтает что-то поменять, ему нужно делать это так, чтобы было выгодно и компании.Один из наших JavaScript-разработчиков хотел возглавить направление по автоматизированному тестированию. Через какое-то время он перестал писать код для приложений и начал курировать вопросы стратегической разработки автотестов во всех наших структурных подразделениях. Другой случай: сотрудник хотел стать руководителем, но оказался не готов. На встрече «1+1» он получил подробный фидбек о том, на каком уровне находится сейчас и над чем ему стоит поработать, прежде чем лидировать команду. После этого у сотрудника было два варианта: либо поверить в фидбек и последовать плану развития, либо уйти в другую компанию, где его навыков хватит. Он ушёл. А было и так, что эксперт захотел стать руководителем, стал им, но в процессе работы понял, что менеджерство ему не подходит. Он вернулся обратно в эксперты — и счастлив.
Перестать всё делать руками
Предположим, ты занимаешь лидирующую позицию естественным образом, без конфликта — то есть сначала завоёвываешь авторитет в команде, коллеги к тебе прислушиваются. Тогда все хорошо, обид не будет. Если в одной команде несколько человек претендуют на роль тимлида, то уже есть вариации. Либо они договариваются тимлидить вместе, распределяя между собой задачи, либо кто-то из них подбирает себе другую команду. Тимлиды знают, кто в чем сильнее — и стараются дополнять друг друга. Задач всем хватает.
Быть хорошим программистом и управлять программистами — не одно и то же. Нужно перестать всё делать руками, нужно научиться доверять людям. А это сложно. Вместо погружения в микроменеджмент и попыток всё тащить через себя ты должен заложить в команду близкие тебе технологические процессы, а команда должна их принять. Например, важно настроить ревью с минимальным твоим включением, настроить линтеры, организовать процессы постановки и приёмки задач и автотестов. Нужно владеть разными инструментами и методологиями командной разработки.
Сейчас на рынке много направлений и вертикального роста, и горизонтального. Зарплаты примерно одинаковые. Развиваться можно в любую сторону. Важны и технические, и гуманитарные навыки. Как пистолет без патронов не имеет смысла, так и патроны без пистолета. Но особенно ценны те люди, которых прёт и то, и другое. Которые на стыке.
Андрей Плахов, руководитель отдела функциональности Поиска
Что важно для роста из разработчика в руководители
Важны три вещи:
— базовый уровень здравомыслия и сознательности (который у нас в индустрии есть почти у всех),
— не считать себя исключительным (а вот с этим у многих гораздо хуже),
— и не считать никого из коллег радикально хуже себя — люди это интуитивно чувствуют.Главное правило такое: верить, что каждый обладает сильными сторонами, которым можно поучиться. Ваш собеседник — живой человек, а не просто смежник, из которого нужно что-то выбить или получить обманом.
Предположим, разработчик достоин повышения по своим хард-скиллам, но его не повышают. Причина обычно в том, что он считает себя настолько более крутым, что даже этого не скрывает. И тогда ему, прежде чем нарабатывать гибкие навыки, нужно такое отношение поменять.
Я не согласен с буддистами в том, что изменение может прийти только изнутри. Человеку проще всего измениться, если он увидит яркий пример, когда он был неправ, и почувствует боль от этого. Легко видеть чужие недостатки, гораздо сложнее осознать свои. Это как разница между гламурными селфи и фотографиями, на которых вы выглядите так, как в реальности.
Какой рост проще
Программирование — медитативное занятие, хорошо подходящее для интровертов, и большинство программистов мечтают о росте вглубь, а не вширь. Что лучше — стать гуру, вокруг которого ходят на цыпочках и который иногда совершает нечто великое, или руководителем, который, наоборот, вокруг всех носится? Второй вариант легче просто по закону спроса и предложения. Расти вширь и заниматься коммуникацией не так рискованно, от вас не требуется ничего уникального. А вот гуру конкурирует со всем миром.
Нельзя быть человеком без подчинённых и не писать код. То, что вы стали экспертом, не означает, что вы куда-то придёте, точечными изменениями в пару строк поменяете мир, и все начнут шептать — «О великий!» Известные мне эксперты пишут много хорошего кода. Он далеко не всегда сверхъестественный, хотя и в нём попадаются вещи, которые я просто не до конца понимаю, и воспринимаю это нормально. Это как читать шахматные партии Магнуса Карлсена. Каждый конкретный ход, наверное, понятен, но в то же время видно, что в целом чемпион что-то понимает гораздо лучше остальных.
Самая важная деятельность эксперта, не связанная с написанием конкретных артефактов, — это код-ревью. На множестве конкретных примеров можно обучить целую школу людей, которые будут знать, что такое писать так же, как pg. Если человек пытается сформулировать общие правила, он передаст свою мудрость не так хорошо, как на конкретных примерах.
Кому не надо идти в руководители? Есть такая фраза — если можешь не писать стихи, не пиши. С руководством всё не так жёстко, но если ты не чувствуешь в себе желания что-то людям сказать, чему-то их научить, если у тебя нет своего видения, как на самом деле всё должно быть устроено в вашей команде, — наверное, ты не получишь удовольствия от руководства. Управлять сложно, муторно и часто неприятно. И единственная компенсация за это, помимо денежной (а разница в деньгах на уровне топовых программистов уже не столь важна), — возможность сделать всё не как обычно, а так, как тебе кажется правильным. Если этого жгучего желания нет, лучше не надо руководить.
Ольга Мегорская, руководитель управления краудсорсинга и платформизации в Яндексе
Не задача, а стартап
Мне кажется, основа профессионального роста — то, как ты воспринимаешь и ведёшь поставленные перед тобой задачи. Любую полученную задачу можно просто взять и сделать, а можно воспринять её как свой маленький продукт, микростартап. И развивать его так, как положено стартапу: увеличивать область его влияния на мир.
С таким подходом люди получают множество возможностей — ты сам формируешь себе поле, в котором дальше будешь расти. Если у тебя сложится масштабная история, компании будет не жалко инвестировать в неё больше ресурсов.
С этой точки зрения нет большой разницы между развитием тебя как руководителя и как эксперта: в одном случае ты развиваешь сферу влияния своего сервиса, в другом — своей экспертизы. Но путь развития чистого эксперта сложнее. Влияние твоей экспертизы на мир драматически не увеличится лишь от того, что ты положил в свою голову очередную единицу знаний: нужно делать так, чтобы твоя экспертиза стала общепринятыми практиками. И в этом плане эксперту тяжелее, потому что если ты руководитель — значит, у тебя есть какие-то дополнительные ресурсы. Если же ты эксперт, то у тебя есть только собственный авторитет. Чтобы расти только в таком качестве, нужно обладать мощной персональной харизмой. Возможно, поэтому таких людей меньше, чем руководителей. Но те, которые есть и успешно по своему пути идут, — это выдающиеся люди.
В моём подразделении никто категорически не отказывался от руководства — какую-нибудь его порцию рано или поздно получают многие. Некоторые чуть дольше сопротивляются. На самом деле, это удивительно: в Яндексе предложений на руководящие места гораздо больше, чем спрос на них. Приходится уговаривать людей, они ломаются, отвечают, что не уверены. Но в целом, мне такая дорожка кажется более прямой.
Способы вырасти постепенно
Для постепенного роста человека у нас есть эффективный институт виртуальных команд, v-teams. Можно договориться, что кандидат на повышение сначала будет руководить виртуальной командой, а потом станет — или не станет — формальным руководителем. Кроме того, у нас много стажёров, можно в любой момент брать и менторить. Это, вполне вероятно, послужит ещё одним промежуточным шагом к управлению командой.
Если тебе как руководителю что-то в своей работе не доставляет удовольствия — не бойся это делегировать. Вместе с командой у тебя появляется и дополнительная сила, в отличие от ситуации, когда ты один. Просто найди то, что тебе не нравится, того, кому это нравится, и дай ему возможность вырасти, делегировав ему эти задачи. Глобальное правило: руководитель должен заниматься только тем, чем не может заниматься его подчинённый. Ты постепенно спускаешь задачи на уровень ниже, твои ребята учатся, спускают ещё ниже, если у вас несколько уровней иерархии. В моей практике это единственный подход, который позволяет поддерживать масштабируемую систему.
Задача руководителя, который номинирует тебя на повышение, — провести его грамотно. Точно не должно быть ситуаций, когда повышение является неожиданностью для человека и/или для команды. Как правило, повышают в тот момент, когда всем, включая команду, понятно, кого нужно повысить и почему. Если есть риск конфликта, можно пойти более деликатным путём типа v-team. С другой стороны, после повышения лучше не загоняться, что «Вчера мы были коллегами, а теперь я руководитель». Нужно принять себя в новой роли. Так будет легче и команде, и тебе самому.
Автор: Леонид Клюев
