Хабрахабр

Горизонтальный vs. вертикальный рост разработчика. Мнения из ivi и Яндекса

Одну из сессий конференции 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. Как правило, повышают в тот момент, когда всем, включая команду, понятно, кого нужно повысить и почему. Нужно принять себя в новой роли. С другой стороны, после повышения лучше не загоняться, что «Вчера мы были коллегами, а теперь я руководитель». Так будет легче и команде, и тебе самому.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть