Как оценить компетенции разработчика приложений

Обновлено: 03.01.2025

Как выстраивать грейдирование разработчиков внутри компании? Что зашивать в мотивацию? Голый оклад, оклад + премия, почасовка? Каким образом оценивать работу программиста? Нужны ли бонусы и премии? Опытом поделились «Нетология», Finch, DD Planet, MediaSoft, Oneway и Digital Wand.

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

Кто-то формирует свою систему грейдов, кто-то не считает это необходимым. А что рассказали опытные команды представителям Pena Production?

Ключевые показатели при формировании грейдов веб-разработчиков

В Oneway учитывается общий объём закрытых задач в часах, пройденные курсы и сданные экзамены («Битрикс24»), определённый набор скиллов и опыт в определённых задачах (матрица компетенций).

В компании MediaSoft не используется система грейдов в привычном понимании и в целом отсутствует традиционное деление разработчиков на классы junior, middle и senior.

Эта классификация достаточно условна: как показывает практика, senior часто называют самого крутого специалиста в компании, и это не отражает ровным счётом ничего, кроме уровня самой компании. При попытке устроиться в большую и серьёзную организацию вроде «Яндекса» такой senior может не пройти даже на позицию junior.

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

В Finch список показателей достаточно большой: качество кода, самостоятельность, проектное разнообразие, профессиональный рост, количество проработанного в компании времени и инициативность.

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

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

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

Не менее важны показатели вроде адекватности оценки сроков исполнителем, своевременное и чёткое выполнение задач.

В команде Finch решили остановиться на четырёх уровнях: junior, middle, middle+ и senior. В компании достаточно много разработчиков, которые находятся на стыке двух уровней — middle и senior. Поэтому и приняли решение ввести дополнительный грейд. Делать больше грейдов при штате 55 человек ребята считают лишним. Возможно, со временем лестница будет больше.

В DD Planet, как и в большинстве ИТ-компаний, всех разработчиков подразделяют на четыре уровня:junior, middle, senior, team leader (тимлид).

К уровню junior формально можно отнести выпускников вузов, которые только начинают карьеру. Предпочтение отдаётся серьёзным техническим вузам, например МГУ (факультеты ВМК, мехмат), МГТУ, МИЭМ, НИУ ВШЭ.

Более продвинутый уровень развития специалиста — middle. Сотрудник ещё не принимает самостоятельных решений, но за ним не надо перепроверять правильность реализованных задач. Руководитель говорит, как и что надо сделать, программист выполняет всё в срок и качественно.

Следующий грейд — senior, или ведущий программист. Специалист может самостоятельно принимать решения и несёт ответственность за их реализацию. Также он способен курировать одного или нескольких программистов уровня junior или middle.

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

У DigitalWand — шесть уровней разработчиков: junior, junior+, middle, middle+, middle++, senior.

Juniorзнает основы своей технологии, может выполнять простые задачи, но пока не готов работать самостоятельно.
Junior+ на простых задачах работает самостоятельно. Умеет применять типовые операции с Git.
Middleполностью самостоятельно решает типовые задачи, однако ему может потребоваться помощь в проектировании, ревью кода.
Middle+ отлично знает фреймворк, на котором работает, начинает осваивать другие фреймворки, уже может помогать junior-программистам.
Middle++ можно доверить работу на production, проведение релизов. Готов заниматься проектированием не слишком сложных систем. Может при необходимости общаться с заказчиком.
Senior имеет в своём арсенале несколько фреймворков, у него есть опыт проектирования и разработки сложных систем.

В «Нетологии» сейчас есть разделение на три стандартных уровня: junior, middle и senior. Каждый уровень предполагает новую ступень профессионального роста. Грубо говоря, чем выше позиция, тем больше разработчик берёт на себя ответственности, разбирается в разных продуктах и может помочь коллегам.

Специалисты уровня senior, например, в компании не только занимаются непосредственно разработкой, их задача — быть ещё и наставниками для новых членов команды.

В студии Oneway рекордное количество уровней — одиннадцать.

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

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

Например, в «Нетологии» внедрён процесс Performance Review, который проходит два раза в год, весной и осенью. Это ретроспективный процесс, где каждый разработчик рассказывает о своих результатах за последние полгода, получает обратную связь от коллег и рекомендации — на что стоит обратить внимание в будущем. Это могут быть как технические навыки, так и личностные качества.

По результатам ревью становится понятно, как сотрудник развивается. Разработчику это помогает не выгореть: он видит результат своей работы и понимает, куда двигаться дальше: что начать делать, что прекратить. А руководителю это позволяет выявить сильные и слабые стороны в команде, чтобы потом с этим работать.

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

В Finch линейные руководители раз в месяц ставят оценки сотрудникам. Критерии оценки формируются из ключевых показателей грейдирования.

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

В DD Planet о переводе программиста на новый уровень задумываются, как только он начинает предлагать решения тех или иных технических вопросов.

Junior ещё в принципе не способен принимать самостоятельные решения. Middle, как правило, решений не принимает, но может правильно выполнять поставленные задачи. Senior способен принимать самостоятельные решения в рамках своей работы. Тимлид же отвечает за архитектуру и глобальные решения на уровне группы разработчиков.

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

В MediaSoft обращают внимание на то, насколько программисту интересно работать. Часто, когда человек «перерастает» свои задачи, он перестаёт предлагать идеи, не выступает с инициативами, не выкладывается, не рассказывает всем и каждому о своём проекте с горящими глазами.

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

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

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

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

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

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

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

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

В Oneway сегодня маржинальность проектов не учитывается.

В команде Finch маржинальную прибыль также не учитывают, но считают такую практику весьма интересной.

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

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

Типовые ли в компании технологии разработки и создаются ли грейды под каждую технологию

У каждого разработчика может быть свой стек технологий, а кто-то владеет сразу несколькими. Как же это учитывать?

DD Planet специализируется на разработке сложных проектов, на 60% типовых решений и технологий приходится 40% нестандартных. В связи с разработкой высоконагруженных проектов, нетиповых задач встречается очень много.

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

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

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

У ребят из Finch единый стек под все проекты. Поэтому проблемы с несколькими стеками нет.

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

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

В DigitalWand есть различные технологии для разработки. Грейды разделены на backend и frontend, вёрстку и JS-разработку. В рамках каждого из направлений также есть деление по технологиям.

В Oneway 90% проектов разрабатываются на «Битрикс24», поэтому все грейды для backend-разработки единые. Отличаются только backend и frontend

Как выстроена система финансовой мотивации в команде, какую модель выбрали и почему

Компания Oneway использует фактическую оплату по часам. Финально каждую задачу оценивает тимлид. Если человек не выписывается в сроки оценки, то получит меньше, если выполняет задачу быстрее, то сможет получить больше.

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

У Finch нет системы премий, штрафов, выплат за мотивированность и всего такого. Есть чёткий фикс на руки, который обговаривается на собеседовании. Бывали случаи, когда ребятам платили премии. Как правило, это были какие-то особые случаи, в которых просто хотелось сделать приятно человеку. Сейчас от этой практики отказались.

Finch — сторонники нематериальных вознаграждений. Любой человек в компании может съездить на конференцию, сходить на курсы, отдохнуть за счёт компании, если он делает свою работу хорошо. Один из ярких примеров – отправка ребят на Бали. В Finch убеждены, что в таких активностях больше толку, чем в ежемесячной премии.

В DD Planet свой подход. Если задача потребовала дополнительного времени и усилий, сотруднику засчитывается овертайм. Оплата переработки производится по двойной ставке. Также предусмотрены премии за проекты, которые сданы вовремя и реализованы качественно. По каждому проекту закладывается премиальный фонд. Эта сумма распределяется между специалистами в зависимости от вклада каждого в этот проект.

В DigitalWand сейчас фиксированный оклад, но ведётся подготовка к новой системе финансовой мотивации — динамический оклад на основании эффективности, в которой зарплата будет состоять из двух частей:

От чего зависит оклад:

Грейд сотрудника.
Эффективность работы группы и команды в целом.

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

Кроме того, оклад старших грейдов зависит от числа разработчиков младших грейдов в группе, а оклад менеджеров — от соотношения количества разработчиков к количеству менеджеров в группе.

Премия зависит от оценок работы сотрудника его группой. Чем выше оценки, тем выше премия. Обязательное условие получения зарплаты — учёт рабочего времени в Redmine.

Сверхурочная работа оплачивается хорошо. Сверхурочные бывают двух видов:

Добровольные, оплачиваются по ставке х1,5.
По просьбе клиента, оплачиваются по ставке х2.

В MediaSoft действует динамическая система финансовой мотивации. Она включает зарплату с фиксированной и переменной частью, а также квартальную премию.

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

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

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

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

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

«Жил-был принц, он хотел взять себе в жены принцессу. Вот он и объехал весь свет. Да повсюду было что-то не то: принцесс было полно, а вот настоящие ли они, этого он никак не мог распознать до конца, всегда с ними было что-то не в порядке»
Г. Х. Андерсен. Принцесса на горошине

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

Когда в EDISON требуется программист, в объявлении указывается степень квалификации. Например, Middle-разработчик. Возникают вопросы от соискателей о дифференциации уровней. Единой классификации степени профессионализма нет. Можно сказать, что Junior — начинающий разработчик с опытом до 2 лет, Middle — от 2. Стаж Senior начинается с 5. На вершине системы уровень Lead, подразумевающий руководство командой специалистов. Но стаж не гарантирует обладание необходимыми навыками. Можно 5 лет плодить сайты-одностраничники и не стать Senior-разработчиком. И наоборот: попав к грамотному наставнику и принимаясь за серьезные задачи, через год достичь уровня «Middle». Об отборе кандидатов в EDISON кратко написано здесь.

Практика предварительной беседы с соискателями не подошла из-за временных затрат. Этап первичного отбора передали специалисту кадровой службы. Сначала соискатель проходит анкетирование, самостоятельно оценивая компетентность в областях программирования по 5-балльной шкале. Указывает срок использования технологии, заполняет таблицу «Выполненные проекты». Полученные сведения дают общее представление об опыте соискателя и профессиональном кругозоре. Начинающим разработчикам свойственно завышать оценку. К примеру, кандидат считает уровень знания Рython на 4, «готов решить любую задачу», а опыт использования языка указывает 2 недели.

Компетентность соискателя оценивается на практике. Кандидат выполняет тестовое задание. На основании анализа определяется уровень.

Первый фактор оценки — время выполнения

На идентичное задание Junior-разработчику понадобится неделя. Senior выполнит тест за несколько часов. Показательна и оценка срока выполнения тестового задания от соискателя. Разработчик уровня «Junior» смотрит на поставленную задачу чересчур оптимистично, недооценивает сложность. И из-за нехватки опыта не укладывается в сроки. Специалист уровня «Middle» склонен пессимистично смотреть на задачу. Сказывается опыт в качестве Junior-разработчика. Чрезмерно увеличивает прогнозируемый срок реализации. Senior-разработчик реалистичен. Закладывает риски разумно без лишнего завышения сроков.

Второй момент — качество кода

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

Сейчас у нас десятки вариантов выполнения проверочного задания. Тестировщики EDISON выбрали 3 фрагмента кода (обработка запроса веб-приложения), написанные на PHP разработчиками разного уровня, и добавили комментарии.

Начнем с примера так называемого «говнокода».

Хранение логина и пароля пользователя в куках. Явная ошибка безопасности. Куки передаются от браузера к серверу при запросе (открытии/обновлении страницы). Потенциальная возможность перехвата.

Определение действий сайта на основе параметра POST-запроса последовательными условными блоками. Код усложняется, становясь громоздким и нечитаемым. Для облегчения реализации задачи опытные программисты придумали маршрутизацию и паттерны, например MVC.

Громоздкий код для элементарных операций. Опытный программист напишет блок в одну строку.

Подстановка параметра GET-запроса (строки, приходящей от пользователя при открытии страницы в браузере) прямо в SQL-запрос (обращение к базе данных). Потенциальная уязвимость в безопасности (SQL-инъекция).

«Echo» в коде является не лучшим решением для вывода текста или верстки в браузер. Усложняет процесс изменения внешнего вида сайта. Верстка должна находиться в отдельных файлах-шаблонах. По аналогии справедливо и для JS-, CSS-вставок. Обязательно разделение по разным файлам, желателен разброс по папкам.

Захардкоденный обработчик события click. Аналогично предыдущему пункту. Весь JS нужно выносить в отдельные файлы.

Код Middle-разработчика прост для понимания и содержит комментарии для разбора сложных участков. Используется ORM (Object-relational mapping) взамен написания нативных запросов к базе. Значительно снижается риск SQL-инъекций. Применяется ООП и MVC.

Различия между Middle- и Senior-разработчиком по фрагменту кода прослеживаются слабо и заключаются в выборе верных архитектурных решений.

Обобщенные критерии оценки сведены в таблицу. Список не ограничивается приведенными примерами.

Критерий оценки	Junior	Middle	Senior
Декомпозиция задачи	Последовательные строчки кода. Copy/paste — для повторного использования кода.	Создает многократно используемые функции/объекты, решающие общие задачи.	Использует соответствующие структуры данных и алгоритмы. Создает общий/объектно-ориентированный код, инкапсулирующий условия задачи.
Декомпозиция системы	Не способен думать о системе сложнее одного класса или файла.	Производит декомпозицию задачи и проектирует систему в пределах одной платформы или технологии.	Визуализирует и проектирует сложные системы с несколькими линейками продуктов, интегрирует с внешними системами. Проектирует системы поддержки работы: мониторинг, генерация отчетов, аварийные переходы на запасные ресурсы.
Общение	Не может выразить свои мысли/идеи. Плохо с правописанием и грамматикой.	Его понимают. Хорошее правописание и грамматика. Общается эффективно.	Понимает и объясняет мысли/дизайн/идеи/специфику в точно выраженной форме. В общении соответствует ситуации.
Организация кода в файле	Нет четкой организации в файле.	Методы сгруппированы логически и по вызовам.	Код разделен на регионы. Имеет грамотные комментарии со ссылками на файлы-исходники.
Организация кода между файлами	Нет четкой организации кода с делением на файлы.	Физический файл выполняет одну функцию. Например, служит для объявления класса или для реализации одного функционала и т. д.	Организация кода на физическом уровне соответствует проекту. Наглядность способа проектирования реализации через имена файлов и структуру папок.
Читабельность кода	Односложные имена.	Хорошие имена файлов, переменных, классов, методов и т. д. Нет длинных функций. Нестандартный код, багфиксы и допущения в коде поясняются комментариями.	Допущения в коде сопровождаются командами Assert. Поток операций в коде естественный (без глубокой вложенности условий или методов).
Безопасное программирование	Не понимает данной концепции.	Проверяет аргументы методов, возвращаемое значение и обработку исключений в потенциально важном коде.	Имеет собственную библиотеку, помогающую в безопасном программировании. Пишет юнит-тесты для имитации сбоев.
Обработка ошибок	Пишет код для «идеального» случая без сбоев.	Обработка ошибок в коде (кидает исключение или генерирует ошибку).	Пишет код с функцией раннего определения ошибок. Придерживается последовательной обработки исключений в слоях кода и формулирует принципы процесса в системе.
Требования	Понимает выставленные требования и пишет код в соответствии со спецификацией.	Видит картину в целом и сразу выявляет дополнительные аспекты с последующим описанием в спецификации. Задает вопросы, касающиеся неучтенных случаев.	Предлагает альтернативы и следует выставленным требованиям, основываясь на собственном опыте.
Базы данных	Знает основы баз данных, транзакции. Пишет простые select-запросы.	Проектирует нормализованные схемы БД с учетом запросов. Умело использует представления, хранимые процедуры, триггеры и собственные типы данных. Понимает разницу между кластеризованными и некластеризованными индексами. Специалист в использовании ORM инструментов.	Осуществляет администрирование, увеличивает производительность и оптимизирует индексы БД. Пишет сложные select-запросы. Заменяет использование курсора вызовами функций SQL. Понимает принципы внутреннего хранения данных и индексов. Имеет представление о создании «зеркал» и репликации БД и т.д.

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

Квалификация IT-специалиста включает в себя соответствующий опыт, знания (запас информации) и профессиональные навыки, так называемые скиллы. Что принято понимать под hard и soft скиллами разработчика вне зависимости от его специализации — рассказывает заместитель генерального директора SimbirSoft, заведующий базовой кафедрой и старший преподаватель УлГТУ Олег Власенко. Рассмотрим также, как меняется список скиллов по мере профессионального развития специалиста.

Этапы роста IT-специалиста

Каждый специалист в IT-отрасли — программист, аналитик, QA-специалист — проходит несколько этапов роста:

Какие навыки нужны начинающим и джунам

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

Онлайн-образование — новая мишень фродеров

Большинство сайтов в категории заражены фрод-скриптами.

Ключевой soft skill — готовность учиться.

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

Как правило, Junior дорастает до Middle не раньше чем за год, а в среднем — за 2–5 лет. Эти годы крайне нужны, чтобы попробовать разные инструменты на практике, поработать в разных проектах, получить опыт решения проблем в реальных условиях с живыми людьми, погрузиться в предметную область и в специфику бизнеса.

Важные hard skills:

знание выбранного языка программирования;

знание по крайней мере одного фреймворка;

знание IDE и средств коллективной разработки (Git и/или других);

умение искать информацию в поисковых системах.

Важные soft skills:

навыки самообучения — самое важное, потому что начинающему предстоит учиться и учиться!

самодисциплина и мотивацию к развитию и самообучению.

Какие навыки нужны мидлу

Уровень Middle предполагает, что разработчик является состоявшимся профессионалом. Он не только обладает обширными теоретическими знаниями, но и имеет значительный опыт работы в реальных проектах. В IT-отрасли такой опыт называют «коммерческим».

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

Hard skills:

глубокие знания используемых языков в коммерческих проектах;

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

Soft skills:

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

если у специалиста есть способности предлагать и отстаивать свои решения, то это поможет ему в управлении, в менторстве, в переговорах с заказчиком;

проактивность помогает открыть двери для перехода на ответственные роли, такие как тимлидер или руководитель группы.

Что ещё характеризует мидла

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

Аналогичная ситуация и с отраслевой и предметной спецификой.

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

По этим причинам нередки случаи, когда в одной организации специалиста оценивают как Middle, но при собеседовании в другой организации ему ставят уровень Junior+ или даже просто Junior. Если специалист планирует в карьере переход в новые организации, то ему полезно специально вкладываться в те знания и компетенции, которые можно перенести в новую предметную область и в новую организацию.

Какие навыки развивать дальше

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

Наконец, дойдя до уровня Middle, можно переключиться на вертикальную карьеру: роль тимлида, руководителя подразделения (менеджера среднего звена), топ-менеджера (CTO), генерального директора (CEO).

Если IT-специалист планирует не останавливаться на этом этапе, а развиваться дальше, то ответ на вопрос «Какие навыки развивать?» сильно зависит от выбранного вектора роста. Так, если специалист готов попробовать свои силы в управлении командой — стать тимлидом, можно говорить о следующих навыках:

умение вдохновлять команду;

умение ставить цели и делегировать задачи;

способности к планированию.

И это всё soft skills. Если специалист выбирает развиваться в сторону сеньора, то список навыков будет таким:

умение решать любые проблемы;

широкий кругозор — знакомство с массой языков программирования, фреймворков, инструментов, отслеживание новинок;

умение быстро осваивать новые технологии и инструменты;

опыт решения разных задач, работы в разных проектах;

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

Заключение

Об этапах пути

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

Дальше он превращается в «джуна» за 2–6 месяцев, если имеет хорошую базовую подготовку. Джун становится мидлом за 2–5 лет работы на реальных проектах. Мидл может стать сеньором за 5–7 лет, а может и никогда не стать, если предпочитает развиваться в других направлениях.

О взаимных требованиях компаний и кандидатов

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

В свою очередь компании даже в условиях постоянной нехватки кадров обращают большое внимание как на hard skills, так и на soft skills, которые определяются ролью специалиста в команде.

Один из ключевых критериев выбора соискателя — увлечённость и страсть к разработке,

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

Что пишут в блогах

Расписание на декабрь
Как вырасти из тестировщика в тест-менеджера
Организация обучения джуниоров внутри команды. 2 декабря, Кострома
Автоматизация рутины. Скачиваем файлы через bash
Панбагон. 12 часов — опасное время
Оффер сразу после курса для тестировщиков с нуля. Что бывает, если выйти из зоны комфорта
Мои 12 недель в году. Часть 17 (переезд, ДР и пневмония)
Как тестировщику с небольшим опытом подготовиться и сдать экзамен ISTQB FL: интервью
Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Публикация компании SEADMEX

Какие классы специалистов будут в нашей компании наиболее востребованными через полгода? Сколько у нас есть людей, способных написать веб-интерфейс к системе Х? А сколько из них сейчас доступно? Но самый главный вопрос — действительно ли эти люди способны написать требуемый веб-интерфейс? Ресурсное планирование, прогнозы загрузки, гарантия качества, оценка при найме — вот для чего нужно в компании-разработчике ПО такое понятие, как «компетенция».

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

Прежде всего, при найме человека не думаем о том, что «нанимаем человека на позицию «Лидер группы разработчиков». Я нанимаю человека с компетенцией «Лидер группы разработчиков» на позицию Разработчик уровня 3. Принципиальных отличий в формулировках вроде бы не видится, но они есть. В чем отличие?

Компетенции

Начнем с того, что такое «компетенция». Компетенция — это набор умений, уровень которых не ниже заданного.

Оценки по уровням умений выставляются следующим образом.

Знает общие принципы

Будучи приложенными к конкретному человеку, они гарантируют, что он способен выполнять определнную роль в проекте. Например, набор умений «Системный архитектор» гарантирует, что данный человек способен выполнять все действия в проекте, которые требуются согласно описанию роли Архитектор. Разумно также дополнить общие знания Системного архитектора знанием конкретной платформы, в которой он работает.

Поясним определение примером.

Умения

Технология

Навыки общения

Бизнес

Presentation skills: 2>
Technical writing: 3>

Техники моделирования

UML language: 3>
Sparx Enterprise: 3>
Rational Rose: 2>
ARIS: 2> (оцпионально )
ErWin: 2> ( опционально )

Человек с набором таких умений уровня не ниже заданного уровня точно сможет быть системным архитектором. Если не все умения в нужном уровне (например, всю жизнь работал в ErWin и лишь «игрался» со Sparx — то нет никакого сомнения, что он изучит и Sparx) или одного-двух нет (использует нотацию Гейна-Сарсона для моделирования — значит, освоит и UML), то его все равно можно брать, оговорив, что он должен получить эти умения во время программы адаптации (см. Программа Адаптации)

Корреляция компетенции и уровня

С тем, что такое «компетенция», разобрались. Теперь что такое «уровень». Уровень — это не более чем позиция в тарифной сетке.

Для последовательных компетенций определенной компетенции соответствует определенный уровень зарплатной сетки. Примеры последовательных компетенций: Разработчик (Уровень 1 зарплатной сетки) – Ключевой разработчик (Уровень 2) — Архитектор (Уровень 3) и т.д.

Табл. 1. Соотношение уровня и последовательной компетенции (выдумано из головы)

При параллельных компетенциях возникают надбавки за дополнительные компетенции. Например, человек имеет основную компетенцию Архитектор и параллельно получает компетенцию Аналитик требований (Уровень 2). Для компании он ценен тем, что на него, например, можно сбросить все работы по спецификации требований и разработке архитектуры — а это работы настолько связанные, что от поручения их одному человеку, который гарантированно выполнит их со всем возможным качеством (что гарантирует компетенция), компания без сомнения выиграет — большая эффективность, меньше затраты времени на коммуникацию и согласование, отсутствие искажений при передаче данных.

Табл. 2. Доплата за параллельную компетенцию (выдумано из головы)

Разработать систему компетенций и (крайне желательно) надбавок в масштабах компании достаточно сложно. Это породит массу вопросов и споров — например, считать Архитектора и Лидера группы последовательными или параллельными компетенциями? Я однозначно считаю, что последовательные: от Лидера требуется гораздо больше умений, чем от Архитектора — все те же знания + организаторские навыки + календарное и сетевое планирование + коммуникации. Однако наверняка найдутся те, кто не согласятся.

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

Определение уровня умений

Теперь самое интересное. Определение действительного, а не задекларированного, уровня умений. Что такое действительный уровень умений? Действительный — это значит «имеющий место быть». Иначе кто-то может задекларировать уровень умений «эксперт», прочитав тонкую брошюрку по теме. Страшно подумать, как «повезет» тем, к кому он попадет на проект. Как определить уровень умений при приеме кандидата? Опять будем смотреть на примере. Пришел к нам на интервью человек, который претендует на компетенцию «Архитектор ПО». Как его проверить? Интервью делим на 2 части — собственно интервью и тест после него.

Интервью

Теперь тестируем его на предмет знания технологий в BrainBench и после задаем ему дополнительные вопросы и тестовую задачу (имплементация класса и юнит тестов к нему).

«Боевая задача» очень хорошо покажет стиль кодирования и знания алгоритмов и структур данных. «Боевая задача» обычно состоит в том, чтобы разработать нечто, руководствуясь принципами SCRUD — снизу вверх, от таблиц сиквела и хранимых процедур до веб-страницы, отображающей информацию. Этим проверяются след. Умения:

Вопросы и задачи на интервью можно формализовать и использовать повторно.

Компетенции или умения? (заметки на полях)

А теперь внимание — вопрос: а в чем различие между умениями (skills) и компетенциями (competencies)? Зачем группировать умения в компетенции?

Ответ простой — ни один навык сам по себе не является достаточным. Архитектор должен не просто уметь кодировать, но должен уметь также и проектировать, и крайне желательно, чтобы он владел соответствующими инструментальными средствами.

Разработчик требований не просто должен уметь писать документы, но также должен уметь извлечь требования из Заказчика.

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

Программа адаптации

Возможно (и скорее всего), человек, которого мы берем, не обладает одним-двумя умениями, которые от него требуются. Тогда он должен получить их во время программы адаптации (обычно занимает порядка трех недель).

Кроме «подтягивания» уровня во время этой программы он изучает следующие вещи:

Обзорно — процессы разработки внутри компании.
Конкретно — PWA и групповой узел проекта и свои действия и обязанности в нем.
Разделение работы внутри группы и его обязанности.
Порядок работы в группе — VSS , подходы к моделированию, инструменты, порядок и время сборки билдов и т.п.

На все время адаптации у него есть куратор (как правило, тим лид или key developer группы, в которую он пришел). Куратор проводит несколько уроков, дает задания на закрепление и консультирует в повседневной работе.

По хорошему конечно очень было бы хорошо если бы был недельный курс для каждой компетенции. Зачем так? Например, пришел новый супер-архитектор. Он привык использовать для обозначения требования символ юзкейса, а мы уже используем символ реквайремента (новая версия языка UML, 2.0). Надо ему рассказать, как его использовать и как устанавливать трэйсабилити — а то он будет делать по своему и всех путать. Вообще же : «Better ways to achieve convergence of method are Training: People do what they know how to do. If you give them all a common core of methods, they will tend use them.» (Peopleware, 2 nd Edition). Я считаю, что каждой уважающей себя компании уже пора иметь корпоративную систему тренингов (набор курсов для каждой компетенции), собственных или отданных на аутсорсинг тренинговой компании. При этом, конечно, крайне желательно договориться об адаптации тренингов под конкретную тренинговую компанию.

Аттестации

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

Кстати, возможно, обновленные балы его компетенции позволят назвать его «экспертом» (см. Ниже).

Отдельной оценкой является Team Work (работа в команде) — социометрическое исследование на тему, сколько членов команды проекта (сотрудников отдела) принимало или отторгало данного человека. Это и многое другое является основанием для начисления баллов в Программе продвижения руководителей, но это тема отдельного большого документа. Могу написать, если интересно.

Также хочется предостеречь от проставления баллов экзаменационным методом советского ВУЗа – по личному мнению преподавателя. Гораздо более целесообразно проводить нечто вроде тестов, которым подвергают Microsoft или Novell. Если уж никуда не деться от аттестации человеком — то попытайтесь придумать что-то, ограждающее от субъективизма аттестующих.

Эксперты

Человек, у которого самый большой балл в данной компетенции, является экспертом на этот квартал. Он получает некое вознаграждение и новые обязанности, как-то: консультирование других, участие в SEPG (группа разработки процессов) или аналогичной тематической группе. Еще одна обязанность — внимание! — обновить существующий тренинг его тематики (например, Leading Development Team для Лидера группы) своими личными идеями и лучшими практиками и прочесть его. Естественно, перед тем, как читать, он пройдет тренинг для тренеров и несколько раз потренируется.

Зачем? Это обеспечит обмен знаниями внутри организации. В нашей Компании это более чем актуально — dp Consulting, разработчик и консультант, поставляет тренеров для SEADMEX. Естественно, тренерами становятся только Эксперты. Это означает, что тренинги для слушателей читают только лучшие-из-лучших-практики, и гарантирует, что их знания — непосредственно «с передовой».

Ресурсное планирование

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

Соответственно для того, чтобы определить «точку дефицита» данного ресурса, достаточно найти пересечение красной и зеленой линий. Это февраль 2006го, значит, в феврале у нас возникнет «ресурсный голод» на специалистов System Architect — . NET Platform . Логично заранее принять меры для того, чтобы подготовить новых специалистов к этому времени.

Кстати, о точности такого метода прогнозирования можно судить ходя бы по тому, как он предсказывает «ресурсный голод» в Компании в июне 2005-го — степень приближения можно оценить прямо на рисунке.

Компетенции как основа кадровой политки

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

Если Вы сейчас думаете, как организовать свой отдел разработки или компанию, специализирующуюся на разработке ПО — то советую начать с разработки системы компетенций. А уже отталкиваясь от нее, Вам будет легко выстроить «зарплатную сетку», спланировать потребности в ресурсах и впоследствии выстроить стройную систему ресурсного планирования.

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

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

Существуют критерии оценки программистов, которые помогают понять, чего стоит конкретный сотрудник.

KPI или Как Платить ИТ-специалисту

Бизнес мечтает о введении KPI (ключевых показателей эффективности) для кодеров. Иначе попробуй, пойми, работает программер или занимается ерундой, мало ему платишь или много. Большинство компаний выставляют собственные критерии эффективности программиста:

ранжировка, отличная от общепринятой (например, junior, junior+, senior, senior+, middle);
объем закрытых за определенный период задач (оплата почасовая, в некоторых фирмах разработаны системы оценки, где стоимость часа зависит от сложности задачи);
экзамены, курсы, повышение скилла;
самостоятельность, инициативность, переработку.

Есть сторонники нематериальных вознаграждений: при хорошем выполнении работы отправляют отдыхать на Бали, предлагают билеты на интересные конференции.

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

Как оценивать программистов при приеме на работу

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

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

способность работать с монотонной рутиной или искать неожиданные решения;
исполнительность или самостоятельность;
умение трудиться в команде, коммуникабельность и пр.

По каким базовым критериям выбирают программиста

Определить, подходит ли вам кандидат, можно по пунктам:

Отношение к программированию, увлеченность, кругозор. Как воспринимает IT-специалист свою деятельность: как средство заработка или дело всей жизни. Чем занят в свободное время: изучает новые технологии, лежит на диване или увлекается посторонним хобби. Страсть к профессии — однозначный показатель, что человек будет работать увлеченно и выдаст максимальный результат.
Обучаемость — с какой скоростью человек усваивает новое, не вызывает ли у него сильный дискомфорт, вплоть до увольнения, необходимость разбираться в незнакомой технологии.
Наличие личных трудов, степень их завершенности.
Образование. Высшее/среднее техническое (или самоучка), знание методов и средств разработки, языков программирования, опыт.

Как оценить разработчика по подходу к написанию кода? Уточните, планирует ли айтишник архитектуру решения или сразу приступает к делу, переписывая код в процессе из-за неправильно выбранной тактики. Это влияет на скорость и результат.

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

Многое зависит от уровня. Новичкам засчитывается энтузиазм, желание разбираться, учиться, расти. У айтишников рангом повыше существенна отдача: насколько быстро выполняется работа, не приходится ли потом переделывать решения. Имеет значение соотношение затрачиваемых ресурсов (время на код, время на тестирование, аналитику), и пользы выполненной работы. Для «мамонтов»-middle важно, насколько код ориентирован на будущие нужды.

Техническая оценка разработчиков

Отсеять нецелевых кандидатов помогут вопросы о специализации. Смотрят на направление, перспективы, общее направление мыслей, логику. Примерные варианты:

На какой области, технологии вы специализируетесь?
Какие инструменты вы выберете для проекта с нуля?
Версия «рабочего» языка, которая вам больше всего нравится.
Есть ли будущее у вашего направления, приведите аргументы.

Вопросы для личностной оценки программистов

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

Определение идеального ИТ-специалиста с вашей точки зрения.
Самые интересные для вас задачи.
Какой коллектив/команда наиболее комфортен для вас.
Опишите работу мечты, идеальный рабочий процесс.

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

Подбор айтишников — сложное занятие, требующее подготовки. Важно анализировать не только технические умения. HR-профессионал в критерии оценки разработчика включает коммуникабельность, понимание запросов клиента и иные важные моменты. Благодаря опыту и регулярному обучению рекрутеры BGStaff владеют всеми инструментами оценки ИТ-специалистов. Обратившись в наше кадровое агентство, вы сможете заполучить к себе в команду человека с нужными навыками и качествами.

По всем вопросам свяжитесь с нами любым удобным способом:

Читайте также: