Привет! Меня зовут Серёжа Елизаров, я руковожу группой системных аналитиков Контур.Банка.

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

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

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

Почему пересобрали матрицу компетенций Контура: 60 навыков → 3 линейки

У нашей старой матрицы было три проблемы:

• Аналитик не понимал, где находится: какой у него грейд и что делать дальше, чтобы расти.

• Руководители не понимали, сколько платить человеку с тем или иным набором компетенций.

• Набор навыков ничего не говорил о результате. Бывало, что у человека много навыков, а результата нет. И наоборот: навыков немного, а результат заметен на уровне команды и выше.

Мы взялись за эти проблемы целенаправленно и пересобрали инструмент оценки. Вместо 60 разрозненных компетенций появились три линейки, которые мы прикладываем к работе всех системных аналитиков:

? аналитические задачи — основа;

? зона ответственности — дополнительно;

? люди: обучение, менторство и руководство — дополнительно.

Так мы перешли от оценки навыков к оценке результата, который аналитик показывает с их помощью.

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

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

Сама оценка аналитических задач строится на двух независимых измерениях:

— сложность задачи: какой уровень работы требовала сама задача;

— работа аналитика: насколько самостоятельно и качественно аналитик эту работу выполнил.

Дальше разберу матрицу по шагам: на каждом из них можно сразу проверить свою задачу.

Если хотите сокращённую версию — перепрыгивайте сразу к шпаргалке.

Попробуйте оценить себя по описанию грейда

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

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

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

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

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

?‍? Мидл+ сам снижает неопределённость: может разобраться в сложных системах, ищет причины проблем, решает, какие исследования нужны, и проектирует решение там, где готового пути нет. 

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

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

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

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

Прикиньте, какой портрет ближе к вам: это первое приближение. Дальше уточним оценку на вашей завершённой задаче.

1. Возьмите задачу с результатом

Выберите то, над чем работали последний год и чем гордитесь больше всего. Описывать удобно в формате self-review. 

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

Дальше self-review сверяют с обратной связью коллег. 

У каждого аналитика два руководителя. Непосредственный ставит задачи и определяет, какого результата ждёт бизнес. Функциональный отвечает за саму роль: решает, как должны работать системные аналитики, и следит, чтобы каждый развивался и работал там, где пригодятся его компетенции. Оба смотрят self-review. 

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

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

2. Оцените сложность задачи, а не свою работу

Этот критерий складывается из нескольких характеристик. Вот вопросы, которые стоит задать себе ↓

• Масштаб. Что меняла задача: один сценарий, функцию внутри продукта или целое бизнес-направление с группой продуктов?

• Неопределённость. Было ли понятно на входе, какую проблему решаем? Какие шаги для ее снижения необходимо было предпринять?

• Техническая глубина. Сколько систем и сервисов затронула задача? Какой технологический ландшафт существует вокруг этой задачи? Какие технические ограничения к решению проблемы существуют?

• Сложность коммуникаций. С кем нужно было договориться? 

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

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

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

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

Если прогнать эту задачу по пунктам выше, она набирает максимум по всем четырём характеристикам:

— масштаб: сервис нужен каждому продукту, который работает с подписью;

— неопределённость: закон ещё не вступил в силу, и практики работы с МЧД ни у кого не было;

— техническая глубина: сценарии и интеграции пришлось продумывать с нуля;

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

3. Оцените, что вы сделали с проблемой

Теперь можно оценить, как поработал аналитик: смотрим, как он исследовал проблему и проектировал решение. 

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

Чтобы разобраться с этим блоком, подойдут такие вопросы ↓

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

• Ответственность за результат. За какую часть решения вы несли ответственность? К каким результатам привело ваше решение? Что делали, когда что-то шло не так?

? По этому критерию довольно легко отличить джуна от мидла или сеньора.

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

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

Я вижу такую развилку ↓

?‍? Джун сказал бы: «Поддержка — это не моя зона влияния», ну, или что-то вроде того.

? ?‍? ? А вот мидл, мидл+ и сеньор подумали бы об этом заранее. А если бы не подумали, то, узнав о проблеме, пошли бы предупреждать поддержку, вести переговоры, искать решения, как снизить нагрузку на первых этапах.  

Общая идея в том, что чем выше грейд, тем больше зон влияния человек берёт на себя.

4. Сложите две оценки

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

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

Иными словами: нам важно увидеть результат там, где он был по-настоящему нужен.

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

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

Помимо аналитической, в нашей матрице есть ещё две линейки — зона ответственности и люди. Вторая делится ещё на два подтипа. 

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

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

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

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

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

Этот трек мы оцениваем начиная с мидла+. Считаем, что джуны и мидлы сначала должны стать хорошими аналитиками.

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

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

Как устроена оценка в общем

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

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

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

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

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

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

Шпаргалка: вопросы для самооценки

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

? Сложность задачи:

— Что меняла задача: сценарий, функцию, продукт или несколько продуктов?

— Было ли понятно на входе, какую проблему решаем?

— Сколько систем и сервисов она затронула?

— С кем пришлось договариваться и на каком уровне?

? Ваша работа:

— Что вы выяснили сами, а что вам принесли готовым?

— Какие варианты решения вы рассматривали и почему выбрали этот?

— О ком вы подумали заранее: о поддержке, маркетинге, смежных командах?

— Что вы делали, когда что-то шло не по плану?

— Как вы поняли, что решили исходную проблему, и что изменилось после релиза?

? Не только задачи:

— Есть ли продукт или сценарий, за который вы отвечаете? В каком состоянии вы его приняли и в каком он сейчас?

— Кому вы помогли вырасти за этот год? 

— Где выступали и какие мастер-классы проводили?

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

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

Я аналитик, поэтому подушню: сначала разобрался бы, зачем компании аналитики и что от них ждут. 

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

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

А как оценивают грейды у вас: по списку навыков, по задачам или по ощущениям руководителя? 

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