Матрица soft skills: как вырасти от стажера до синьора

Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS.

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

Главный вопрос, на который я попытаюсь ответить: чем отличаются сотрудники разных грейдов от стажера до синьора. В сообществе есть негласное понимание этих отличий: джун только начинает, у миддла побольше опыта, синьор совсем крутой, а тимлид почти не программирует, он в основном управляет командой. Эти формулировки очень размыты, и при этом каждая компания по-своему различает грейды.

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

Это сравнение можно наглядно представить в виде таблицы – матрицы компетенций. Такой матрицей пользуемся и мы в KTS – в конце я расскажу о ней подробнее.

Оглавление

Основные понятия

Понятие «soft skills» довольно растяжимое, и каждый человек по-своему представляет себе перечень таких компетенций.

Когда мы говорим о софт скиллах, мы подразумеваем все навыки и знания, которые не являются техническими. Иными словами – все, что нужно уметь разработчику, но не относится напрямую к работе с конкретными технологиями и инструментами.

Чтобы оценить софт скиллы сотрудника, мы смотрим на следующие показатели и навыки:

Объем опыта. Важна не цифра сама по себе. Опыт косвенно отражает степень знакомства разработчика с основными процессами, его погруженность в специфику задач своего профиля и понимание того, как создается ценность для заинтересованной стороны (заказчика в широком смысле). Все это – конкретные софт скиллз, и мы смотрим на стаж как на очень простой и относительно надежный показатель владения ими.
Ответственность. В данном случае мы имеем в виду не способность соблюдать дедлайны (что тоже, безусловно, важно), а максимальную зону ответственности, которую может взять на себя сотрудник.
Качество и сложность задач. Соотношение рутинного и исследовательского компонентов в задачах разработчика показывает, насколько он готов выходить за рамки привычных типовых действий и искать решение самостоятельно.
Достаточная постановка задач. Здесь нас интересует объем и точность входных данных, необходимых разработчику для выполнения задачи.
Точность оценок. Навык самостоятельного прогнозирования сроков выполнения задач.
Навыки проектирования. Умение продумывать и создавать архитектуру системы. Этот пункт нельзя строго отнести к софт скиллам, и я даже рассматривал его в своей статье о технических навыках фронтендера. Однако для разработки архитектуры недостаточно владеть нужными инструментами и подгонять связи между компонентами под базовые принципы проектирования: нужно уметь подключать логику и здравый смысл, поэтому мы рассматриваем проектирование как смежный навык между софт и хард скиллами.
Делегирование и обучение. Готовность и умение сотрудника распределять задачи в команде, обучать, мотивировать и продвигать младших коллег.
Код-ревью. Частное проявление более широкого навыка – оценки работы коллег. У код-ревью есть свои особенности, поэтому этот пункт занимает отдельное место в списке.
Вовлеченность в процессы. Здесь мы предлагаем смотреть, насколько сотрудник погружен в работу команды, и насколько он может и хочет ее улучшать.
Управление требованиями. Навык валидации требований к задачам на соответствие здравому смыслу, ТЗ и продуктовой ценности.

Грейды

Всего я рассмотрю пять грейдов — стажер, джун, миддл, синьор и тимлид. Поехали.

Стажер

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

У стажера нет коммерческого опыта. Это его ключевое отличие от джуна.
Зона ответственности стажера минимальна. Поскольку у стажера нет опыта, он еще не знает, как «надо», а только учится делать свои задачи. Стажеру нужно много внимания более опытного коллеги, который отвечает за результаты работы стажера. Проще говоря, косяки стажера — это косяки наставника.
Качество и сложность задач. Стажер делает самые простые и понятные типовые задачи. Если он может делать что‑то более сложное — отлично, но в общем случае от него этого не ожидают. У стажера нет опыта, для него все новое, поэтому даже за простыми задачами он не заскучает, зато они позволят ему погрузиться процессы и не впасть в ступор от завышенных требований.
Постановка задач для стажера должна включать максимально подробные входные данные: что уже есть, что нужно сделать и каким образом это сделать.
Поскольку стажер смутно представляет, сколько времени занимает решение той или иной задачи, он не оценивает сроки самостоятельно — с эстимейтами ему помогает наставник. Стажер при этом только учится планировать свое рабочее время.
С навыками проектирования еще проще — на уровне стажера о них еще рано говорить.
Делегированием и обучением стажер не занимается. Пока что обучают его самого.
Стажер в общем случае не проводит код‑ревью. Он может изучить изменения от своих коллег в образовательных целях, но никто не ожидает от него глубоких комментариев.
Большой вовлеченности в процессы от стажера тоже не ожидают — на начальном этапе хватит и наблюдательности, способности понять в общих чертах, что вообще происходит.
И, наконец, в вопросе управления требованиями новичок также не обязан ориентироваться. Здорово, если он хотя бы примерно понимает, что цель любого бизнеса — создать ценность для заинтересованной стороны (или сторон). А понимание конкретных требований этих сторон придет к нему с практикой. На первых же порах он старается задавать как можно больше уточняющих вопросов, которые помогут ему понять конечный смысл выполнения его задач.

Резюмируя вышесказанное, основная цель стажера — научиться работать «как все».

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

макет страницы;
документацию API;
подсказки по решению задачи («кнопка должна принимать такие-то параметры, вызывать метод, который выполняет такой-то запрос»).

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

Джун

Джун — это тоже младший сотрудник, однако в силу своих компетенций и опыта он уже обладает большей автономией, чем стажер. Следовательно, требования к джуну тоже несколько выше.

Ключевое отличие джуна от стажера — у джуна уже есть коммерческий опыт. В среднем разработчики становятся джунами через 6–12 месяцев.
Джун тоже отвечает только за свои задачи. Однако от стажера его отличает более четкая зона ответственности: наставники не выступают промежуточным звеном между ним и командой, и свои ошибки джун исправляет сам.
Качество и сложность задач: в основном джун работает с простыми и понятно описанными задачами, и предполагается, что с ними он будет справляться быстро, качественно и самостоятельно. При этом джун время от времени берется за более сложные задачи под руководством наставника.
Простые задачи для джуна подразумевают простую постановку: с ними он должен справляться, имея на входе только желаемый результат («что сделать»). При этом важно помнить, что типовые таски не всегда бывают легкими, и для решения более комплексных задач джун также получает на вход подсказки («что и как сделать»). С исследовательскими задачами джуны работают крайне редко, разве что в образовательных целях.
В вопросах оценки времязатрат джун также более самостоятелен, чем стажер: он способен дать довольно точный прогноз сроков решения собственных небольших типовых задач по аналогии с уже выполненными.
Джун постепенно развивает свои навыки проектирования: например, изучает архитектурные схемы и читает о подходах в разработке.
Поскольку джуны отвечают только за свои задачи, они не делегируют их выполнение коллегам. К обучению стажеров их также рано привлекать.
А вот к код‑ревью небольших задач джуны могут постепенно подключаться. Поначалу ревью от джуна не достаточно — после него задачу должен проверить более опытный коллега.
В построение процессов в команде джун не вовлекается, однако сами процессы он должен знать, понимать и следовать им без помощи ментора.
И, наконец, от джуна ожидается некоторая проактивность в управлении требованиями: иногда он замечает недостаток требований к задаче и задает уточняющие вопросы.

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

Поговорим о классической задаче для джуна на примере все той же кнопки «лайк» для новостей. На этом грейде разработчику не нужно рассказывать о том, как её сделать. Джуну достаточно доступа к макету страницы и документации API.

Миддл

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

Обычно на уровень миддла переходят после двух-трех лет коммерческого опыта в своей сфере. За это время человек успевает освоить подходы к решению практически всех типовых задач.
Отвечает миддл не только за тикеты, которые висят на нем в трекере задач. В его зону ответственности может входить разработка части проекта, например, какой-то конкретной фичи.
С точки зрения качества и сложности задач миддл уметь стабильно и качественно выполнять объемные таски и самостоятельно отличать типовые от исследовательских. Работая над последними, миддл учится самостоятельно управлять временем и глубиной их решения. Также он может подключаться к решению инфраструктурных задач, что требует знаний в смежных сферах.
Миддл способен декомпозировать объемные задачи из своей сферы, поэтому постановка типовых задач любого размера для такого разработчика включает только желаемый результат («что сделать»). При этом инфраструктурные и исследовательские задачи для миддла все еще могут включать подсказки.
В вопросе самостоятельности от миддла ожидается точная оценка времязатрат на задачи по своему направлению.
Миддл подключается к проектированию архитектуры отдельных частей системы.
Несмотря на то, что миддл-разработчик только учится делегированию, он уже участвует в распределении задач и направляет младших коллег. Более того, уверенный миддл уже может обучать стажера.
Миддл регулярно и стабильно качественно проводит код‑ревью типовых задач любого размера по своему направлению. При этом он наблюдает за код‑ревью исследовательских и инфраструктурных задач в учебных целях.
От миддла ожидается не просто следование процессам в команде: он проактивно участвует в них, иногда предлагая улучшения.
Миддл ориентируется в управлении требованиями с точки зрения бизнеса. Это означает, что он понимает продуктовые ожидания и всегда удостоверяется, что задача им соответствует. Также он учится валидировать продуктовую ценность задач и может предлагать корректировки, если задачу можно решить более оптимально с точки зрения затрат на реализацию и сложности поддержки.

Итого, миддл — это сотрудник, который уже полноценно подключает к работе гибкие навыки. Он учится управлять не только своими ресурсами, но и временем младших коллег. Он ставит задачи, учитывая не только желаемый результат, но и уровень погруженности исполнителей. Он пробует совершенствовать процессы вместе с командой и учитывать не только требования к своим задачам, но и их предполагаемую ценность.

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

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

На вход к этой объемной задаче миддлу тоже достаточно макета и документации API. При этом он может декомпозировать ее на типовые задачи: реализация текстовых блоков, медиаконтента, рекламных баннеров, функциональных кнопок и т. д. По возможности миддл перекладывает выполнение этих задач на плечи стажеров и джунов; при этом он делится с ними практическим опытом, а сам учится делегировать обязанности. Миддл подключается к коммуникации со смежными командами. Например, он может участвовать в проектировании API для фичи, за разработку которой отвечает.

Синьор

Синьор обладает достаточными навыками, чтобы решать любые задачи в своей сфере, разумно управляя своими ресурсами и учитывая ресурсы коллег.

Обычно необходимые для синьорского грейда навыки формируются у разработчика за пять лет. Этого срока хватает не только на то, чтобы полноценно овладеть нужными компетенциями в своей сфере, но и научиться ориентироваться в смежных.
Синьор может отвечать за значительную часть проекта, а иногда — за небольшой проект целиком. Еще, как вариант, синьор может полностью взять на себя проектирование архитектурного среза проекта.
Качество и сложность задач синьора могут быть любыми — подразумевается, что он стабильно выполняет типовые, исследовательские и инфраструктурные задачи независимо от их размера.
Синьор работает с абстрактной постановкой задач: «сделай проект», «сделай фичу». Более того, он может сам ставить себе задачи. При работе над проектом он разбивает его на составляющие — типовые, исследовательские и инфраструктурные задачи — и определяет очередность их выполнения.
В вопросе оценки затрат времени от синьора ожидается не просто точность эстимейтов, а грамотное управление ими с учетом соотношения цены и ценности. Он должен понимать, в какой срок смогут выполнить ту или иную задачу его коллеги.
Синьор должен уметь проектировать сложные технические системы с учетом их бизнес‑ценности. Эту ценность он может обосновать, выступая представителем команды для защиты собственных архитектурных решений перед бизнесом, заказчиком или смежными командами.
В отличие от миддла, синьор регулярно ведет стажеров, занимается обучением младших коллег и делегирует им задачи.
Апрув синьора играет решающую роль в код‑ревью любой задачи в рамках проекта.
Уровень вовлеченности синьора в процессы подразумевает, что настолько опытный разработчик регулярно инициирует улучшения в процессах с учетом изменяющегося рабочего контекста.
Синьор не просто валидирует свои задачи на соответствие требованиям, но и отслеживает бизнесовую ценность своей работы. Он понимает, когда следует корректировать не просто постановку отдельных задач, а вектор работ в целом, если видит более оптимальные способы закрытия потребностей заказчика. Более того, синьору хватает компетенций для того, чтобы выделить MVP проекта.

По сути, само название грейда отражает его значение: синьор — это старший разработчик. Цель синьора заключается в оптимизации проектов, участии в активностях компании, наставничестве и проектировании. Синьор понимает важность и действует с учетом баланса собственных интересов, интересов разработки и бизнеса.

Вернемся к примерам задач. Формулировка задачи синьора может звучать так: «добавить новостной раздел на сайт». Синьор самостоятельно может спроектировать API, обсудить все детали со смежными командами, учесть ограничения дизайна и уточнить бизнес‑требования. Затем он запланирует работы над этой фичей, при необходимости инициирует привлечение дополнительных разработчиков.

Тимлид

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

Чтобы стать тимлидом, разработчику нужно как минимум пройти путь от стажера до уверенного миддла. В это время он учится управлять процессами, ресурсами, корректировать требования под ожидания заказчиков. И если с годами сотрудник понимает, что управлять ему нравится больше, чем писать код, его дорога лежит в тимлиды.

Тимлидами, как и синьорами, становятся разработчики с пятью и более годами стажа за плечами.
В зону ответственности тимлида может входить крупный проект или несколько проектов одновременно — их количество будет зависеть от специфики работы команды.
Говорить о качестве и сложности задач тимлида затруднительно — в основном он не занимается ими, а сосредотачивает усилия на управлении.
Следовательно, отдельные задачи перед ним также не ставятся. Классическую постановку запроса к тимлиду можно упростить до фразы «сделай проект или фичу вовремя и в нужном объеме».
Тимлид планирует рабочее время всей команды. При прогнозировании сроков он полагается как на собственный опыт, так и на самостоятельность своих коллег.
Тимлид может делегировать проектирование синьорам, а не заниматься им собственноручно. Затем он валидирует результат их работы на соответствие бизнес‑ценности и техническим ограничениям.
Собственно, делегирование и является ключевым навыком тимлида. Профессиональный рост до этого уровня возможен только через качественное распределение обязанностей, задач и ролей между коллегами.
В контексте код‑ревью основная обязанность тимлида — не проверять чужие задачи, а выстраивать процесс распределения ревью задач в команде. Ревью нужно назначать так, чтобы каждая задача была проверена оптимальными усилиями и вовремя. При этом знания о проекте должны распределяться равномерно, а в нагрузке на коллег не должен возникать дисбаланс.
Тимлиды занимаются формированием процессов в команде и непрерывно отслеживают «здоровье» коллектива. Для этого нужны и теоретические знания, и практические навыки развития командной работы, но главное — внутренняя мотивация человека развивать коллег, поднимать уровень их вовлеченности и инициативности.
Требованиями тимлиды управляют в полной мере.

Во‑первых, они контролируют и стремятся увеличить бизнес‑ценность труда. Для этого они соотносят потребности заказчика и возможности команды. Иногда реальные потребности клиента отличаются от заявленных: например, за запросом «добавьте на сайт четыре новых раздела» может стоять необходимость упростить навигацию для пользователей, и талант тимлида — это нащупать истинную цель и предложить разумные варианты ее достижения.

Во-вторых, тимлид анализирует деятельность команды на соответствие целям бизнеса и отсекает все лишнее. Закрывать потребности клиента можно по-разному, и тимлид должен уметь предложить наиболее оптимальный способ.

Таким образом, цель тимлида – это руководство разработкой проектов, построение продуктивной коммуникации с бизнесом, постоянное совершенствование внутренних процессов и инициирование активностей в компании.

На примере этой роли нагляднее всего прослеживается связь между навыками, которые мы относим к гибким, и общепринятому пониманию софт скиллз. Чтобы мотивировать коллег, тимлиду нужно лидерство; чтобы качественно распределять задачи, нужны организаторские способности; чтобы взаимодействовать с бизнесом, нужны навыки коммуникации и так далее.

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

С какой же конкретной задачей может работать тимлид? Например, точкой входа в задачу (а точнее, в проект) может быть формулировка «нужно сделать новостной сайт за полтора месяца, бюджет – X миллионов рублей».

Основные ресурсы тимлида, которыми он будет пользоваться для реализации такого проекта – это компетенции его коллег, время и бюджет. Чтобы использовать эти ресурсы эффективно, он должен и обладать перечисленными гибкими навыками, и владеть информацией о возможностях своей команды.

Матрица компетенций

Итак, мы определились, в какой степени должны быть развиты гибкие навыки у сотрудников разных грейдов. Попробуем визуализировать это соотношение в виде таблицы:

Условные обозначения, которые мы использовали здесь, не так важны. Важна идея: для перехода на следующий грейд сотруднику необходимо развивать каждый из перечисленных скиллов.

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

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

Собственно, поэтому в KTS за каждым сотрудником закреплен ментор. Он обеспечивает последовательную прокачку необходимых навыков у своих подопечных с помощью следующего алгоритма:

Отталкиваясь от матрицы компетенций KTS, наставник составляет индивидуальные планы развития сотрудников.
Наставник проводит регулярные встречи с теми, кого он менторит. Эти встречи проходят один на один (отсюда обозначение «1-1»), и их частота может меняться в зависимости от потребностей каждого сотрудника.
На самих встречах наставники проводят performance review – анализируют, насколько качественно разработчик справляется с поставленными задачами и как их выполнение способствует развитию необходимых навыков.
По итогам performance review наставник совместно с сотрудником калибруют новые цели и ожидаемые результаты.

Заключение

Карьерный рост разработчика не ограничивается прокачкой технических навыков. Он подразумевает всестороннее развитие и накопление опыта, с которым формируется более глубокое понимание целей бизнеса и способов их достижения.

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

Основная рекомендация, которую я хочу дать менторам, менеджерам и тимлидам – создавайте в своем коллективе условия, при которых ваши сотрудники смогут не только выполнять рутинные таски, но и расти как специалисты. Не загружайте стажеров исключительно стажерскими задачами, старайтесь понемногу открывать перед ними простор для исследования. Постепенное увеличение качества и сложности задач не даст вашим коллегам заскучать и поможет им развивать как технические, так и нетехнические компетенции.

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

К слову о балансе. Если вам скоро предстоит собеседование, рекомендую не ограничиваться моим материалом о софт скиллах. Подробнее о хардах, необходимых фронтендерам, мы писали здесь:

Можете использовать эти статьи как чеклисты и проверить, с какими из технологий, востребованных в среде разработки фронтенда, вы знакомы. А если вам интересно узнать больше о самих технологиях – мы регулярно рассказываем и о них:

И главное – никогда не прекращайте учиться!

ссылка на оригинал статьи https://habr.com/ru/articles/862348/