Почти 6 лет мы в WPP.DIGITAL использовали классические грейды, чтобы оценивать квалификацию наших разработчиков. За это время пережили многое: проводили многочасовые интервью, шлифовали матрицу компетенций, убеждали сеньоров не скромничать, а джунов – не быть слишком уверенными в себе.  Но вопросы все равно оставались: что делать, когда разработчик крут в одном стеке, но новичок в другом? Какой у него грейд? И главное – отражают ли оценки реальную эффективность специалиста?

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

Как внедряли грейдирование

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

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

«Нашли матрицу компетенций, посмотрели, она оказалась классной. Поняли, что половину из того, что там указано, мы и сами еще не знали. То есть даже для собственного развития она подходила очень хорошо, а уж джунов гонять, так это вообще милое дело. Немного поправили под свои нужды, потому что в первоначальном виде таблица была довольно обобщенной, такой Computer Science в вакууме. И направлена скорее на бэкендера, а не фронтендера или мобилиста, поэтому добавили части, которые были интересны именно нам – это софт-скиллы и фронт»

Антон Седов

технический директор wpp.digital

Дальше определили грейды разработчиков и условились раз в полгода их пересматривать. Этот процесс разделили на 2 этапа:

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

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

Минусы классического грейдирования

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

1. Огромные временные затраты.

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

Изначально у меня на одного человека уходило примерно 6 часов, то есть я тратил на одно ревью почти целый рабочий день. Тогда у нас в штате было не меньше 25 разработчиков. Старался их разбивать по дням, потому что даже два интервью провести друг за другом – с ума сойти можно, плюс другие задачи копятся. Позднее, когда позвал на помощь еще 2-х руководителей, старались уложиться в 4 часа. Первая половина была технической, выясняли хард-скиллы, как разработчик владеет своим стеком, а вторую посвящали софтам»

Антон Седов

технический директор wpp.digital

2. Субъективность оценок.

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

«Джуны завышали оценки, а мидлы и сеньоры часто занижали. Приходилось долго бодаться с ними на one-to-one. Ты видишь, что разработчик — сеньор, а он ставит себе тройки. Почему? Приглашаешь на интервью и выясняется, что занизил в общем-то совершенно напрасно. Например, потому что генераторы знает на уровне языка программирования, но не разбирается, как они преобразуются в CST, AST и байт-код. Джуны даже слов таких не понимают и ставят пятерки, а этот знает и ставит тройки. Выяснить реальные компетенции было очень тяжело».

Антон Седов

технический директор wpp.digital

3. Специфика проектов.

Как it-подрядчик мы работаем с разными проектами, и их разнообразие затрудняло грейдирование внутри агентства. Допустим, в первом проекте нужен один стек технологий, во втором – уже другой, даже если он на том же языке. Разработчик может не знать второй стек или иметь небольшой опыт работы с ним. То есть его ценность внутри конкретного проекта может быть ниже, хотя в другом он будет вести себя как мидл и замечательно ориентироваться в задачах.

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

4. Сложность привязки к системе мотивации.

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

«Есть ровные сотрудники: они до мидла доросли и больше ни вправо, ни влево. Они счастливы на своем уровне, им не нужны сверхапы до сеньоров. Но актуализировать зарплату все равно нужно – не получится говорить, что раз грейд не повысил, то платить будем столько же, как и 3 года назад. Формально – могли не повышать, потому что были разработчики, которые на протяжении 4-х грейдирований показывали одинаковый результат, ничего не менялось по оценкам. Но 3 года – это пропасть в it. Можно легко потерять таких ровных сотрудников, которые хорошо выполняют типовые для себя задачи»

Антон Седов

технический директор wpp.digital

5. Разные ожидания в найме.

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

«У нас в голове есть картинка, что мидл – это 2 года активной практической работы, вряд ли меньше. А вот у кандидата, скажем, только год опыта коммерческой разработки. Возникает вопрос: когда он успел стать мидлом? Вероятно, за такой короткий промежуток времени он просто не попадал в те ситуации, где можно стать мидлом. Хорошая работа на одном проекте еще не значит, что человек стал крепким специалистом. Тут важен опыт и широта знаний, чтобы разработчик поработал в разных командах, на разных проектах. Все это конвертируется в полезные умения»

Василий Гребенников

директор wpp.digital

Когда наступил переломный момент

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

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

Считаем эффективность через баги

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

«Не мы авторы идеи, подсмотрели ее у более крупных компаний. Это здравая мысль, она лежит на поверхности. Есть объем работы и количество ошибок во время ее выполнения. Решили, что это хороший показатель для оценки качества труда разработчика. Условно говоря, берется время, которое специалист зафиксировал на выполнение задач, и сравнивается со временем на устранение ошибок. Если он 10 часов потратил на разработку и 3 часа на исправление, то у него 30% ошибок, а эффективность работы – 70%»

Василий Гребенников

директор wpp.digital

Показатель существует в 3-х измерениях:

1. Количество багов в продакшене. Не более одного за релиз.

2. Плотность багов на задачу (количество багов / количество задач). Следим, чтобы было меньше единицы, в будущем планируем ужесточить до 0.5 – 0.3.

3. Плотность багов на разработчика (количество багов / количество задач). Здесь пороговых значений не устанавливали, собираем и анализируем статистику. 

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

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

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

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

Планы на будущее

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

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

Василий Гребенников

директор wpp.digital

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

«Принцип "мужик сказал — мужик сделал" здесь срабатывает не всегда. Иногда задачу получается закрыть позднее, чем рассчитывал изначально. Попасть в свою оценку – это особый скилл. Есть вполне нормальные практики, когда менеджмент получает задачу от разработки и увеличивает срок ее выполнения в 2 раза, очень многие так делают»

Антон Седов

технический директор wpp.digital

Интересно, что стопроцентное попадание в оценки тоже может быть сигналом. Если разработчик выполняет задачи точно в заявленные сроки, возникает вопрос: не работает ли он по шаблону? Творческие проекты с неизвестными участками почти всегда вынуждают разработчиков корректировать первоначальные оценки. Для некоторых специалистов комфортная зона – предсказуемые задачи, и это нормально. Но бывает так, что сотрудник страдает от отсутствия роста на однотипных задачах. Поэтому метрику потенциально можно рассматривать в контексте общего профессионального развития сотрудника и его удовлетворенности работой.

Есть ли правильный путь???

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

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