Что не так с оценкой Avito?

Оценка разработчиков — один из самых сложных и конфликтных процессов в IT-компаниях.

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

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

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

Напомню масштаб: 2700 разработчиков, 15 млн версий объявлений в день. Это огромная разработческая машина. Для сравнения: в момент продажи Instagram — 9 человек, у Notion — 13, Telegram — до 30.

Карта построена по принципу: “вот стандарт поведения, вот кто и как по нему оценивает”. Например:

На уровне тимлида (E5) пишут: “выступает фича-лидом, отвечает за реализацию фичи, устраняет техническую неопределённость”. На уровне E8 — “знает техстратегию компании, работает с долгосрочными целями, видит проблемы, мешающие бизнесу”.

И всё это — прекрасные, правильные фразы. Только вот…

Почти все формулировки — про поведение, а не про результат. Ты можешь “писать DRY”, “быть проактивным”, “выступать фича-лидом” — и при этом:

Более того, даже понятия вроде “качество” не калибруются по уровню задачи. Если ты хорошо делаешь средние задачи, но не справляешься со сложными — какую оценку ты получаешь? Неясно.

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

Разработчик должен получать фидбэк в реальном времени. DORA подчёркивает: быстрый фидбэк и автоматизация code review куда важнее, чем “соблюдение DRY”.

Вопросы про “следует стандартам” бессмысленны, если у тебя уже есть статанализаторы и инструменты оценки кода.

Формулировки про “ответственность”, “прозрачность”, “участие в планировании” — хороши, но:

Реальный результат — это когда задача приносит ценность без постоянного контроля. Авито этого почти не оценивает.

Когда оценка — это “кто как участвует”, а не “кто приносит результат”, появляется смещение:

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

2. Делить задачи по размеру.Важно понимать: какую задачу и какой сложности я могу доверить человеку? И с какой вероятностью она будет сделана без моих правок?

3. Убрать субъективные критерии про стиль.KISS, DRY, читабельность — пусть оценивает ИИ и CI. Это не должно быть частью субъективной оценки.

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

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

Хочешь сильную команду — оценивай результат. Остальное — ритуалы.

Если тема интересна — на своём канале я регулярно разбираю такие кейсы.