Сеньор за 3 года, а не за 10. Карьерный компас для 1С-разработчика: матрица компетенций + пошаговый план прокачки

Введение

Всем привет! Меня зовут Айдар Сафин. Я главный разработчик 1С в MAGNIT TECH.

Пять лет я был Middle и не понимал почему. Закрывал задачи, писал код, получал зарплату. А на performance review мне говорили «ты молодец, но до Senior ещё расти» — и я не понимал, что конкретно имеется в виду. Архитектура? Интеграции? Лидерство? Общение с бизнесом?

Тогда я сел и разобрался. Разложил карьеру 1С-разработчика на шесть грейдов — от Junior до CTO. Для каждого описал: что должен знать, что уметь, какие фишки использовать, как прокачать каждый навык. Получился карьерный компас — матрица компетенций плюс пошаговый план роста.

С этим компасом я за год вырос до Senior, ещё через два — до главного разработчика. От Junior до Senior — три года, не десять. Потому что появилась система. Я перестал учить «всё подряд» и начал точечно закрывать разрывы.

Важно понимать: то, что вы прочитаете ниже — это моё видение того, как должна быть устроена карьера 1С-разработчика. Я не претендую на истину в последней инстанции. Это не ГОСТ и не официальный стандарт. Это система, которую я собрал из личного опыта, наблюдений за коллегами, обсуждений на конференциях и анализа десятков команд.

Но я надеюсь, что это послужит эталоном для 1С-сообщества. Что тимлиды возьмут эту матрицу и адаптируют под свои команды. Что разработчики перестанут гадать «а что мне учить?» и получат конкретный ответ. Что HR сможет объективно оценивать кандидатов, а не спорить «он Middle или Senior?».

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

В этой статье я делюсь системой. Вы сможете:

• Понять где застряли — проведёте самооценку по матрице компетенций и увидите, каких навыков не хватает именно вам
• Увидеть куда расти — поймёте что отличает Middle от Senior, Senior от Lead, Lead от Architect
• Узнать как прокачаться — получите пошаговый план: какой навык, какими фишками, в каком порядке
• Построить маршрут — составите IDP (Individual Development Plan — индивидуальный план развития) на 6 месяцев с измеримыми результатами

Поехали.

Почему в 1С нет чётких грейдов

В экосистеме 1С есть «1С:Специалист» и «1С:Эксперт». Но это экзамены на знание платформы, а не грейды разработчика. Они проверяют умение решать задачи по партиям, рассчитывать себестоимость, настраивать РАУЗ. Но не проверяют архитектурные навыки, софт-скиллы, бизнес-компетенции.

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

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

На Инфостарте эту проблему уже поднимали. В статье «Грейды разработчиков 1С: от хаоса к порядку» автор описывает три типа компаний, где грейды формируются по-разному — стартапы, IT-отделы в бизнесе и IT-компании. В статье «От стажёра до эксперта: матрица компетенций разработчика 1С» показан опыт внедрения системы грейдов с балльной оценкой и привязкой к 1С:ЗУП. Эти материалы полезны и важны. Но между ними есть разрыв: первая описывает проблему и типологию компаний, вторая — конкретную корпоративную систему. Мне же хотелось создать инструмент, который разработчик может взять и применить самостоятельно — без ожидания, пока HR внедрит грейды у него в компании.

Результат отсутствия стандарта: разброс зарплат в 2-3 раза на одной должности. Я часто слышал: «в прошлой компании я был Senior, а в другой Middle».

Что такое карьерный компас

Карьерный компас — это навигатор, который показывает:

• Где вы сейчас
• Какие навыки у вас есть
• Каких не хватает для следующего грейда
• Что конкретно нужно делать чтобы расти

Не абстрактное «учи архитектуру». А конкретное: «научиться проектировать REST API (Representational State Transfer API — программный интерфейс для обмена данными по HTTP), спроектировать подсистему с нуля, провести три архитектурных ревью».

Компас состоит из частей:

1. Модель компетенций — три группы навыков
2. Матрица грейдов — что должен уметь каждый уровень
3. Инструмент самооценки — где вы сейчас и куда двигаться
4. План действий — IDP, чек-листы, анализ разрывов

Матрица компетенций 1С-разработчика

Три группы навыков

Все компетенции 1С-разработчика делятся на три группы.

Hard Skills — технические навыки. Платформа 1С, базы данных, интеграции, DevOps, тестирование, безопасность.

Soft Skills — коммуникация и лидерство. Коммуникация, менторинг, лидерство, переговоры, презентации.

Business Skills — бизнес и продукт. Понимание бизнес-процессов, продукта, рынка, экономики разработки.

Каждая группа важна на каждом грейде. Но в разной пропорции.

Откуда взялись пропорции. Это не ГОСТ и не результат научного исследования. Это моё обобщение: личный опыт, наблюдения за коллегами на разных грейдах, обсуждения на конференциях, разбор десятков команд. Цифры — ориентир, а не догма. Если в вашей компании Senior — это 50% Hard Skills, это нормально. Важно не точное соотношение, а сам принцип: с ростом грейда доля Hard Skills падает, а Soft и Business растёт. Исключение — Architect: у него Hard Skills снова подскакивает до 50%, потому что это техническая роль, просто на другом уровне — не «писать код», а «проектировать системы».

Сразу видно как меняются пропорции. Junior — почти всё Hard Skills. CTO — половина Business Skills.

Ключевой инсайт: переход с Senior на Lead — это не технический рост. Это смена профиля: меньше кода, больше людей. Многие Senior не хотят становиться Lead потому что «не хочу переставать писать код». Это нормально. Есть второй трек — Architect.

Ключевые переходы между грейдами:

• Junior → Middle: из исполнителя в самостоятельного разработчика. Учится проектировать модули.
• Middle → Senior: из разработчика в технического лидера. Берёт ответственность за систему.
• Senior → Lead: из техлида в менеджера. Управляет командой, сроками, людьми.
• Lead → Architect: из менеджера в стратега. Определяет технологическое направление.
• Architect → CTO: из стратега в руководителя бизнеса. Технологии служат бизнесу.

Hard Skills — технические навыки

Платформа 1С:Предприятие

Базы данных и SQL

Интеграции и обмены данными

DevOps и CI/CD

Тестирование и качество

Безопасность

Soft Skills — коммуникация и лидерство

Коммуникация

Менторинг и развитие других

Лидерство и управление

Business Skills — бизнес и продукт

Предметная область

Продуктовое мышление

Экономика разработки

Шесть грейдов: подробный разбор

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

Junior — фундамент

Суть роли: исполнитель. Пишет код по готовым спецификациям.

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

Срок до следующего грейда: 12-18 месяцев.

Что меняется по сравнению с предыдущим уровнем: это старт. До Junior — стажёр или ученик курсов. Junior уже пишет рабочий код, но под контролем ментора.

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

Пример задачи с разбором: Требуется написать внешний отчёт по продажам за период с группировкой по менеджерам и развёрнутой аналитикой по номенклатуре.

Джун начинает с макета: какие колонки, какие группировки. Потом пишет запрос с соединением двух таблиц — Продажи и Справочник Менеджеры. Делает форму с параметрами даты. Подключает СКД для группировок. На код-ревью ментор спрашивает: «А почему не через временную таблицу?» — и джун учится. А потом замечает сам: отчёт тормозит на больших периодах — предлагает добавить индекс. Ментор одобряет. Это уже зачаток Middle-мышления.

Практическое задание: написать три внешних отчёта на СКД с разной сложностью группировок. В первом — одна группировка, во втором — две с иерархией, в третьём — условное оформление.

Типичные ловушки:

• Сидеть над проблемой полдня, потому что «не хочу беспокоить ментора». Это не упорство, это потеря времени.
• Учиться «по курсам», не читая чужой код.
• Формулировать поисковый запрос как «1С ошибка» — и удивляться, что ответа нет.

Как прокачать:

1. Правило 20 минут. Если не можете решить проблему 20 минут — идите к ментору. Не 2 часа, не полдня. 20 минут.

2. Писать код каждый день. Без исключений. Даже 30 минут лучше, чем ничего.
3. Читать чужой код 30 минут в день. Звучит банально, но это работает. Я сам так делал — открывал модули типовых конфигураций и просто читал, как написан код БСП. Иногда это было полезнее любых курсов.
4. Дневник обучения. Записывайте каждый день: что изучил, что не понял, что запомнить. Через полгода — это ваша личная база знаний.
5. «Гуглить» — это навык. Плохой запрос: «1С ошибка». Хороший: «1С Предприятие 8.3 ошибка при записи документа "Значение не является значением объектного типа"». Второй даст ответ за 30 секунд.
6. Не бояться задавать вопросы.
7. Изучить основы SQL и баз данных.
8. Через полгода — самооценка снова.

Middle — самостоятельность

Суть роли: самостоятельный разработчик. Решает задачи без менторства.

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

Срок до следующего грейда: 18-24 месяца.

Что меняется: Middle уже не ждёт, пока ему дадут спецификацию. Он сам обсуждает с аналитиком, что нужно сделать, и сам предлагает решение. Разница между Junior и Middle — не в объёме знаний, а в готовности брать ответственность за результат.

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

Пример задачи с разбором: Нужно реализовать автозаполнение маршрутов доставки в УТ на основе истории заказов клиента.

Мидл начинает с анализа: какие данные есть, какие алгоритмы применить. Проектирует регистр сведений для хранения маршрутов. Пишет обработку заполнения с запросом по истории. Добавляет индекс для ускорения. Делает команду в форме документа. Тестирует на реальной базе. На код-ревью ему говорят: «А что если исторических данных нет?» — и он добавляет обработку пустого результата.

Практическое задание: спроектировать подсистему уведомлений пользователей. Два типа уведомлений — информационные и требующие действия. Настроить права. Сделать форму списка и форму элемента.

Типичные ловушки:

• Застрял в комфорте — решает знакомые задачи, не берётся за новое.

  Важная оговорка: когда расти некуда

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

  Я встречал джунов с опытом 5–6 лет — это не редкость. Они делают рутину за полтора МРОТ, а компании большего и не надо. Причина чаще всего одна — боятся переходить, боятся браться за легаси. Придётся напрягаться в условиях стресса, а это больно. Хотя enterprise без легаси не бывает, и в 1С — тем более.

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

• Бросается писать код, не подумав. Мидл, который сразу пишет, — это джун с опытом.
• Игнорирует код-ревью как «формальность». А это бесплатный менторинг.

Как прокачать:

1. Проектировать больше, писать меньше. Мидл, который сразу бросается писать код, — это джун с опытом. Мидл, который сначала думает — настоящий мидл.
2. Техника «два прохода» при чтении кода. Первый — бегло, чтобы понять структуру. Второй — медленно, по процедурам. Читать чужой код по 30 минут в день.
3. Оценка задач. Разбить на подзадачи, добавить 30% на непредвиденное, 20% на тестирование, 10% на код-ревью. Я внедрил это правило у себя — и перестал сдавать задачи в последний день спринта.
4. Код-ревью — бесплатный менторинг. Задавайте вопросы: «А почему так лучше?», «А где почитать?».

5. Сценарные тесты. Vanessa Automation — это не сложно. Один раз настроив, вы будете запускать сценарий за 10 секунд вместо 10 минут ручного тестирования.
6. Менторить джунов.
7. Изучить интеграции (Kafka, gRPC (gRPC Remote Procedure Calls — удалённый вызов процедур)).
8. Начать оптимизировать производительность.
9. Через полгода — самооценка снова.

Senior — ответственность за систему

Суть роли: технический лидер. Принимает технические решения и отвечает за них.

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

Точка бифуркации: дальше два трека — Lead (управление людьми) или Architect (управление технологиями).

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

Пример задачи с разбором: Бизнес хочет отдать часть документооборота во внешнюю систему. Нужно спроектировать интеграцию между 1С:ERP и внешней DMS (Document Management System — система управления документами).

Сеньор начинает не с кода, а с вопросов: какой объём документов? Какая задержка допустима? Что важнее — надёжность или скорость? По итогам выбирает архитектуру: Kafka для асинхронного обмена, REST API для синхронных запросов. Описывает решение в ADR (Architecture Decision Records — записи об архитектурных решениях): что решили, почему, какие альтернативы отвергли. Спустя год, когда кто-то спросит «почему Kafka, а не RabbitMQ?» — ответ будет готов.

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

Типичные ловушки:

• Стал незаменимым и задушил рост команды. «Только Серёжа знает, как работает эта подсистема».
• Спорит с DBA вместо того, чтобы поставить замеры с обеих сторон.
• Предлагает технологию, потому что «модно», а не потому что посчитал.

Как прокачать:

1. Определиться с треком. Это самое важное решение после Senior. Если тянете к людям — Lead. К технологиям — Architect.
2. Использовать ADR. Каждое архитектурное решение — в отдельный файл. Что решили, почему, какие альтернативы. Всё будет в репозитории — и любой разработчик сможет прочитать.
3. Освоить двустороннюю корреляцию в диагностике. Не спорить с DBA (Database Administrator — администратор баз данных). Поставить замеры на обеих сторонах — приложение и база. Разница — чистое сетевое время. Однажды я три дня доказывал DBA, что проблема не в запросе, а в сети. Когда поставили замеры с обеих сторон — за час нашли узкое место на балансировщике.
4. Считать ROI (Return on Investment — возврат на инвестиции) технических инициатив. Захотели переписать модуль на новую архитектуру? Посчитайте, сколько это стоит и сколько сэкономит. Без цифр бизнес не даст бюджет.
5. Растить себе замену. Сеньор, который незаменим — бутылочное горлышко. Не будьте Серёжей.
6. Не пишите код в пятницу после обеда. По нашим метрикам — 40% инцидентов на проде приходится на коммиты после 16:00 пятницы.
7. Через полгода — самооценка снова.

Lead — управление командой

Суть роли: управленец. Отвечает за команду, сроки, качество.

Ключевые навыки: управление людьми, найм, 1-1, бюджет, метрики (lead time, throughput).

Что важно: Lead пишет код меньше 30% времени. Если больше — это не Lead, а Senior с дополнительной нагрузкой.

Типичный рабочий день: утро — стендап, разбор блокеров. День — 1-1 с разработчиками, ревью метрик. Вечер — планирование, работа со стейкхолдерами. Кода почти нет.

Пример задачи с разбором: Команда из 5 человек не успевает за спринтом. Lead time растёт, моральное состояние падает.

Лид не бросается помогать писать код. Он разбирается: где узкое место. Анализирует метрики — оказывается, 40% времени уходит на согласования с другими отделами. Лид идёт к руководителю смежного отдела и договаривается о процессе. Внедряет правило: согласование — не дольше 24 часов, эскалация — через 48. Через два спринта lead time падает на 30%.

Практическое задание: провести пять встреч 1-1 с разработчиками по шаблону развивающей обратной связи. Внедрить одну метрику и отследить её три спринта.

Типичные ловушки:

• Продолжает писать код вместо управления. Это не Lead, а Senior с дополнительной нагрузкой.
• Превращает 1-1 в статус-встречу по задачам. Это микроменеджмент.
• Решает проблемы команды сам, вместо того чтобы спросить: «А как ты сам думаешь решить?».

Как прокачать:

1. Проводить регулярные 1-1. Обсуждать человека: как себя чувствует, куда хочет расти, что мешает. Не превращать 1-1 в статус-встречу по задачам.
2. Освоить технику развивающей обратной связи.
3. Научиться решать проблемы команды, а не технические. Спросите: «А как ты сам думаешь решить?»
4. Внедрить метрики (lead time, throughput).
5. Проводить ретро без поиска виноватых. Не «кто деплоил?». А «почему система позволила?». Один мой знакомый лид ввёл правило: на ретро запрещено называть имена. Только процессы. Моральный климат в команде изменился за месяц.
6. Убирайте препятствия, а не создавайте. Если команда тратит 30% времени на согласования — проблема в процессе.
7. Растить себе замену.
8. Через полгода — самооценка снова.

Architect — техническая стратегия

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

Ключевые навыки: проектирование корпоративных систем, выбор технологий, ADR, TCO (Total Cost of Ownership — совокупная стоимость владения).

Что важно: Architect не управляет людьми напрямую. Его власть — экспертиза. Он убеждает, а не приказывает.

Типичный рабочий день: утро — архитектурное ревью. День — проектирование новой подсистемы, обсуждение с CIO (Chief Information Officer — директор по ИТ). Вечер — работа с командами: помощь в реализации архитектурных решений.

Пример задачи с разбором: Компания открывает новый склад. Нужно спроектировать обмен между 1С:ERP и WMS (Warehouse Management System — система управления складом) нового склада.

Архитектор начинает с контекста: какие объёмы, какие требования к доступности, какие риски. Описывает контекст на C4 Model (модель C4 — Context, Containers, Components, Code — послойная визуализация архитектуры). Уровень контекста — для стейкхолдеров, уровень контейнеров — для разработчиков. Считает TCO на 5 лет: разработка, лицензии, поддержка, риски. Сравнивает три варианта: Kafka, RabbitMQ, прямой REST. Делает trade-off analysis (анализ компромиссов): Kafka — надёжнее, но дороже в обслуживании; RabbitMQ — проще, но меньше масштабируется; REST — быстрый старт, но проблемы при росте. Рекомендует Kafka, оформляет ADR, защищает перед стейкхолдерами.

Практическое задание: спроектировать архитектуру интеграции между двумя системами. Описать на C4 Model, посчитать TCO, оформить ADR, провести защиту решения.

Типичные ловушки:

• «Архитектор в башне из слоновой кости». Рисует красивые схемы и исчезает. Команды потом мучаются.
• Предлагает Kafka, потому что «модно», а не потому что посчитал TCO.
• Отрывается от команд и теряет связь с реальностью реализации.

Как прокачать:

1. Проектировать системы под бизнес-стратегию, а не под технологии. Архитектор, который предлагает Kafka, потому что «модно» — это энтузиаст. Архитектор предлагает Kafka, потому что посчитал TCO и понял, что на 5 лет это дешевле.
2. Использовать C4 Model для визуализации. Каждый уровень — для своей аудитории. Стейкхолдерам — контекст, разработчикам — контейнеры.
3. Считать TCO на 5 лет. Разработка, лицензии, поддержка, риски. Без расчёта это гадание.
4. Не быть «архитектором в башне из слоновой кости». 30% времени — в командах.
5. Trade-off analysis. Любое решение — компромисс. Не бывает «просто хорошо».
6. Выступать на конференциях. Это развивает навык убеждения и формирует репутацию.
7. Через полгода — самооценка снова.

CTO — технологический бизнес

Суть роли: руководитель технологического бизнеса.

Ключевые навыки: технологическая стратегия, бюджет, build vs buy (сделать самим или купить готовое), публичность.

Что важно: здесь технологии служат бизнесу, а не наоборот. CTO, который спорит с CEO о «правильной архитектуре», проигрывает. CTO, который показывает, как технологии зарабатывают деньги, — выигрывает.

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

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

CTO не смотрит на технологии. Он смотрит на деньги. Считает P&L (Profit and Loss — отчёт о прибылях и убытках) обоих вариантов. Своя разработка: 15 человеко-лет, 30 млн на 3 года, плюс риски найма и удержания. Готовое решение: 10 млн лицензия, 5 млн интеграция, 2 млн в год поддержка. Считает unit economics (пошаговую экономику продукта): на 5 лет готовое решение дешевле, но даёт меньше гибкости. Принимает решение: купить, кастомизировать под себя, через 3 года — оценить, стоит ли переписывать.

Практическое задание: посчитать TCO и ROI для решения build vs buy по реальному кейсу. Оформить решение в формате презентации для стейкхолдеров.

Типичные ловушки:

• Спорит с CEO о «правильной архитектуре» вместо того, чтобы показать, как технологии зарабатывают деньги.
• Считает build vs buy один раз и больше не пересматривает.
• Забывает растить преемников.

Как прокачать:

1. Освоить финансовую грамотность (P&L, unit economics, ROI). Без этого вы не CTO, а техдиректор без финансовой базы.
2. Build vs buy — на миллионы. Считать TCO на 5 лет. Каждый раз — заново. Иногда «своё» дороже, иногда — дешевле.
3. Публичность — часть работы. Выступления, статьи, участие в сообществах. Это не «по желанию».

4. Растить преемников. Один-два Technical Director, которые могут занять ваше место.
5. Читать бизнес-литературу. Не только техническую. «Good Strategy / Bad Strategy» Румельта, «The Lean Startup» Риса, «Measure What Matters» Доэрра.
6. Следить за трендами через технологический радар.
7. Через полгода — самооценка снова.

Как пользоваться компасом

Шаг 1: Самооценка

Оцените себя по шкале 1-5 для каждого навыка:

• 1 — Нет опыта
• 2 — Делал под руководством
• 3 — Делаю самостоятельно
• 4 — Могу научить других
• 5 — Определяю стандарты

Пройдите по всем трём группам — Hard, Soft, Business — и оцените каждый навык из матрицы выше. Честно. Не «в принципе могу» — а «делаю сейчас».

Шаг 2: Определите разрывы

Сравните свою оценку с целевой для желаемого грейда. Найдите топ-5 навыков, где разрыв максимальный.

Вот как выглядит анализ разрывов для целевого грейда Senior:

Целевой грейд: senior

Ожидаемый уровень навыков:

  hard_skills.platform: 4

  hard_skills.databases: 4

  hard_skills.integrations: 4

  hard_skills.devops: 3

  hard_skills.testing: 4

  hard_skills.security: 3

  soft_skills.communication: 4

  soft_skills.mentoring: 4

  soft_skills.leadership: 4

  business_skills.business_domain: 4

  business_skills.product: 3

  business_skills.economics: 3

Пример анализа разрывов (самооценка — заглушка):

Топ-5 навыков для развития:

  1. soft_skills.mentoring: 1/5 -> цель 4/5 (разрыв: 3)

  2. hard_skills.integrations: 2/5 -> цель 4/5 (разрыв: 2)

  3. business_skills.business_domain: 2/5 -> цель 4/5 (разрыв: 2)

  4. hard_skills.devops: 2/5 -> цель 3/5 (разрыв: 1)

  5. soft_skills.communication: 3/5 -> цель 4/5 (разрыв: 1)

Сразу понятно что подтягивать в первую очередь. Менторинг — разрыв 3. Интеграции — разрыв 2. Предметная область — разрыв 2.

Тот же расчёт можно сделать в Excel или Google-таблице: выписать все навыки, проставить свою оценку и целевую, посчитать разницу, отсортировать по убыванию.

Шаг 3: Составьте IDP

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

Шаблон IDP:

Разработчик: [ФИО], [текущий грейд], [опыт в годах]

Целевой грейд: [целевой]

Горизонт: [срок]

Цель N: [Название навыка] (уровень [текущий] → [целевой])

Почему важно: [обоснование]

Что делать:

- [конкретное действие] — [срок]

- [конкретное действие] — [срок]

Измеримый результат: [как поймёте, что цель достигнута]

Шаг 4: Регулярный ревью

Раз в квартал пересматривайте самооценку. Отмечайте прогресс. Корректируйте план.

Пример IDP: Middle → Senior

Разработчик: Анна 

Текущий грейд: Middle 

Целевой грейд: Senior 

Горизонт планирования: 6 месяцев

Контекст

Анна работает 4 года в 1С-разработке. Middle с подтверждённым опытом. Хочет вырасти до Senior.

Самооценка выявила ключевые разрывы:

• soft_skills.mentoring: 1/5 → цель 4/5 (разрыв: 3)
• hard_skills.integrations: 2/5 → цель 4/5 (разрыв: 2)
• business_skills.business_domain: 2/5 → цель 4/5 (разрыв: 2)
• hard_skills.devops: 2/5 → цель 3/5 (разрыв: 1)
• soft_skills.communication: 3/5 → цель 4/5 (разрыв: 1)

Цели развития

Цель 1: Интеграции (уровень 2 → 4)

Почему важно: Senior проектирует интеграционную архитектуру.

План действий:

• Пройти курс по Apache Kafka — месяц 1
• Настроить Kafka в тестовом контуре — месяц 2
• Спроектировать интеграцию с маркетплейсом на реальном проекте — месяц 3-4
• Провести презентацию для команды «Kafka для 1С» — месяц 4

Измеримый результат:

• Самостоятельно спроектировала и запустила интеграцию с маркетплейсом
• Интеграция обрабатывает не менее 10 000 сообщений в сутки
• Метрики: throughput, latency, error rate в норме

Цель 2: Менторинг (уровень 1 → 4)

Почему важно: Senior менторит мидлов и джунов. Без этого нельзя стать сеньором.

План действий:

• Взять двух джунов на менторство — месяц 1
• Проводить парное программирование 2 раза в неделю — месяц 1-6
• Провести 10 код-ревью с развивающей обратной связью — месяц 2-6
• Провести воркшоп «Как писать модульные тесты для 1С» — месяц 5

Измеримый результат:

• Менти закончили испытательный срок с положительной оценкой
• Менти самостоятельно закрывают задачи среднего уровня
• Получила положительную обратную связь от менти

Цель 3: Предметная область (уровень 2 → 4)

Почему важно: Senior говорит с заказчиком на равных, понимает бизнес.

План действий:

• Пройти курс «Управление производством в ERP» — месяц 2
• Провести 5 интервью с заказчиками — месяц 3
• Самостоятельно провести предпроектное обследование — месяц 5

Измеримый результат:

• Провела обследование без помощи
• Заказчик принял результаты обследования
• Подготовила отчёт с архитектурным предложением

Регулярные активности

• Парное программирование с наставником — 2 раза в неделю
• Код-ревью: 3 PR в неделю
• Участие в архитектурных обсуждениях — еженедельно
• Чтение: 1 техническая статья в день
• Выступление: 1 доклад в квартал

Поддержка

Ментор: Иван Петров, Senior 1С-разработчик Встречи 1-1: каждые 2 недели

Ресурсы:

• Курс по Kafka (Stepik) — 5 000 руб
• Курс «Управление производством в ERP» — 30 000 руб
• Книга «Kafka: The Definitive Guide» — 3 000 руб

Итого бюджет: 38 000 руб. Это пример для конкретного случая — многие ресурсы можно заменить бесплатными: документация Kafka, статьи, видео на YouTube. Бюджет зависит от того, что готов оплатить работодатель.

Промежуточные проверки

Критерии успеха

Через 6 месяцев Анна должна:

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

При выполнении всех критериев — заявка на повышение до Senior.

Как использовать компас на performance review

Без компаса:

Тимлид: «Ты молодец, но до Senior ещё расти». Разработчик: «А что конкретно?» Тимлид: «Ну, больше ответственности, архитектура...» Разработчик: «А что я должен уметь чтобы стать Senior?» Тимлид: «...» (открывает зарплатную вилку)

С компасом:

Тимлид: «Смотри. По матрице компетенций у тебя Hard Skills на 4, Soft Skills на 2, Business Skills на 2. Для Senior нужно Hard 4, Soft 4, Business 4. Провал — в Soft Skills: менторинг и коммуникация. Провал — в Business Skills: предметная область. Давай составим IDP на 6 месяцев.» Разработчик: «Понял. Мне нужно взять джуна на менторство и пройти курс по бизнес-процессам. Тогда через полгода я буду готов к повышению.»

Что это меняет:

• Performance review из субъективного «молодец/не молодец» становится объективным
• Разработчик понимает конкретные шаги, а не абстрактные пожелания
• Тимлид может обосновать решение о повышении или отказе

Чек-лист для повышения

Перед разговором с руководителем проверьте:

• Проведена самооценка по всем группам навыков
• Определён целевой грейд
• Найдены топ-5 навыков с максимальным разрывом
• Составлен IDP с измеримыми результатами
• Собраны конкретные примеры из работы за последние 6 месяцев
• Подготовлены метрики: что улучшилось благодаря моей работе
• Собрана обратная связь от коллег и заказчиков

Что говорить на встрече:

1. Начните с результатов, а не с просьбы о повышении
2. Покажите прогресс по IDP: что закрыли, что осталось
3. Приведите 3-5 конкретных примеров, где вы проявили себя на целевом грейде
4. Предложите следующий IDP — покажите, что рост продолжается

Что спрашивать:

• Что конкретно мешает повышению прямо сейчас?
• Какие навыки нужно подтянуть?
• Какие задачи на ближайший квартал помогут закрыть разрывы?

Если повысили:

• Обсудите новые метрики и ожидания
• Согласуйте пересмотр зарплаты
• Составьте новый IDP на следующий грейд

Если отложили:

• Запросите конкретные критерии: что должно измениться
• Зафиксируйте срок следующего ревью
• Обновите IDP с учётом замечаний

Если отказали:

• Попросите развёрнутую обратную связь
• Сравните с самооценкой: где расходятся
• Решите: дорастить здесь или искать команду, где ваш уровень востребован

Мой путь: Middle → Senior → Главный разработчик

Пять лет я был Middle. Не потому что не хватало знаний — их было даже с избытком. А потому что не понимал, чего именно не хватает. Учил всё подряд: то Kafka, то новую версию платформы, то паттерны проектирования. Знания копились, грейд не менялся.

Перелом наступил, когда я разложил требования к Senior на конкретные навыки и честно оценил себя по каждому. Оказалось: Hard Skills у меня на уровне 4 — я действительно писал сложный код и оптимизировал запросы. А вот Soft Skills — на 2. Менторинга не было вообще. С бизнесом не общался — только через аналитика. Business Skills — на 2.

Три навыка, которые дали основной рывок:

1. Менторинг. Я взял двух джунов. Первые месяцы было тяжело: объяснять очевидные вещи, переделывать за ними код. Но именно через менторинг я сам начал понимать платформу глубже — когда объясняешь, находишь пробелы в собственном знании.
2. Предметная область. Я перестал говорить «это к аналитику» и пошёл на встречи с заказчиками. Через полгода я уже сам проводил предпроектные обследования. Это изменило всё: я начал предлагать решения, а не просто реализовывать чужие.
3. ADR. Начал вести записи об архитектурных решениях. Сначала для себя. Потом их стали читать коллеги. Через год я защищал архитектуру перед стейкхолдерами — без страха, потому что у меня были записаны все аргументы.

Через год после старта этой системы я стал Senior. Ещё через два — главным разработчиком. Разница не в количестве знаний, а в том, что я перестал учить «всё подряд» и начал точечно закрывать разрывы.

Для тимлидов: как адаптировать матрицу под свою команду

Если вы хотите внедрить компас в команде — вот 7 шагов:

1. Проведите самооценку команды. Каждый разработчик оценивает себя по матрице. Анонимно или открыто — решайте сами.
2. Согласуйте целевые уровни. Для каждого грейда — свой набор требований. Не копируйте мои цифры слепо: адаптируйте под стек и специфику.
3. Проведите индивидуальные встречи. Обсудите с каждым: где он сейчас, куда хочет, какой разрыв.
4. Встройте в 1-1. Раз в месяц — ревью прогресса по IDP.
5. Согласуйте с HR. Если есть система грейдов — синхронизируйте. Если нет — матрица станет её основой.
6. Встройте в performance review. Замените «ты молодец, но» на конкретику по навыкам.
7. Пересматривайте раз в полгода. Матрица — живой инструмент. Меняется стек, меняются требования.

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

Чем это отличается от других подходов

Итоги и что делать завтра

Ключевые мысли:

1. Сертификации 1С проверяют знание платформы, но не проверяют архитектуру, софт-скиллы, бизнес-компетенции. После Middle они перестают быть сигналом.
2. С ростом грейда меняются пропорции навыков: Junior — 80% Hard Skills, CTO — 50% Business Skills. Исключение — Architect: у него Hard Skills снова 50%, но на другом уровне.
3. Шесть грейдов: Junior (исполнитель), Middle (самостоятельный), Senior (технический лидер), Lead (управленец), Architect (стратег), CTO (бизнес-лидер).
4. После Senior — два трека: Lead (люди и доставка) или Architect (технологии и стратегия).
5. Карьерный компас делает performance review объективным.
6. IDP превращает «куда расти» в конкретный план на 6 месяцев с измеримыми результатами.

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

Что делать завтра:

1. Проведите самооценку по матрице компетенций. Где вы сейчас?
2. Определите целевой грейд на ближайшие 6-12 месяцев.
3. Выберите 2-3 навыка с максимальным разрывом. Составьте IDP.
4. Найдите ментора, который уже на целевом грейде.
5. Покажите компас тимлиду. Предложите использовать на следующем performance review.

Айдар Сафин

Главный разработчик Центра экспертизы 1С

MAGNIT TECH