Грейды разработчиков 1С: от хаоса к порядку

Мой путь в сфере информационных технологий начался в 2005 году. С 2007 года я начал писать код на платформе 1С. Первые шаги были сделаны в условиях, которые сейчас могут показаться почти экстремальными: у меня не было доступа к интернету, а единственной доступной документацией был «Синтаксис-помощник» и развернутая конфигурация «Торговля и склад». Моей первой задачей была загрузка данных из другой системы в 1С. Используя метод проб и ошибок, я смог разобраться с этим, опираясь только на «Синтаксис-помощник». В качестве вознаграждения мне вручили ноутбук — по тем временам это были довольно значительные деньги.

Со временем я столкнулся с проблемой выбора направления для развития. Мне было непонятно, какие книги читать, какие темы изучать. Качественных материалов тогда было недостаточно. Однако с появлением интернета и специализированных сайтов, таких как «Инфостарт», ситуация начала меняться. Я читал и изучал, но в итоге пришел к важному выводу: часто решение бизнес-проблем требует не столько написания кода, сколько коммуникации и достижения договоренностей. Увидел, что можно оптимизировать процессы, наладить взаимодействие между отделами, привлечь дополнительных специалистов. Этот опыт привел меня к руководящей должности в отделе.

С приходом новых разработчиков 1С я снова столкнулся с вызовами: как их развивать, особенно когда их стало несколько? Как оценить их работу, если они решают разные задачи разными методами? Постепенно начали формироваться первые системы оценки, но они были еще незрелыми. С ростом опыта и расширением команды появились более серьезные системы грейдов. Однако каждая попытка их внедрения или улучшения сопровождалась определенными трудностями. Именно поэтому я хочу поделиться своим опытом — надеюсь, моя статья окажется полезной для многих.

Моя цель – «нанести непоправимую пользу». Я хочу помочь:

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

• Опытным специалистам: понять, как влиять на систему, работая внутри компании.

• Руководителям: найти вдохновение и идеи, если они уже начали работу над грейдами.

В этой статье я хочу разобрать основные моменты, связанные с грейдами:

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

2. Почему внутри одной компании возникают разногласия? Объясню, почему даже коллеги по команде могут по-разному оценивать уровень специалиста.

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

4. Путь к порядку: опыт внедрения. Расскажу о личном опыте и опыте компании: с какими проблемами мы столкнулись, какие инструменты использовали, какие планы на будущее сформировали.

Почему так сложно определиться с уровнем грейда

Почему в одной компании вы – «джун», перейдя в другую, становитесь «сеньором», а в другой всю жизнь остаетесь «программистом 1С»? Я выделил три условных типа компаний, объясняющих эти различия.

Стартапы. Главное здесь – скорость доставки продукта (MVP, релиз). Ключевые факторы: скорость решения задач, многозадачность. Грейды либо отсутствуют, либо очень условны. Как правило, быстро растут «специалисты-молнии» – те, кто может очень быстро сделать MVP (визуально работающий функционал для демонстрации, пусть и с компромиссом по качеству). Такой специалист быстро дорастет до сеньора внутри стартапа. Однако при переходе, например, в бизнес-компанию, его навыки могут не оценить (например, спросят про знание логистики). Формализм здесь исключен, главное – результат. Грейды формируются под этот принцип.

IT-отдел в бизнесе. Здесь критически важно знание предметной области. В банках – это безопасность и работа с персональными данными, в логистике – понимание процессов и архитектуры не только 1С, но и реальной топологии складов (адресное хранение, Order Picking и т.д.). Мотивация фокусируется на предметных знаниях и доказательстве бизнес-ценности решений. Ключевым значением при приоритизации разработки является расчет экономии для бизнеса.

IT-компании. Фокус не только на профессиональных навыках и предметных знаниях, но и на маркетинговой активности, развитии специалистов (наставничество, передача знаний). Карьерный рост здесь более прогнозируем, но и происходит дольше, чем в стартапах или бизнес-отделах.

Часто встречается ситуация, когда в компании был один программист, которого назначили ведущим программистом. При появлении новых сотрудников их оценивали относительно него: «слабее» – младший, «сильнее» – эксперт. Со временем этот первый специалист мог вырасти в навыках или уйти из компании, однако должность ведущего программиста осталась привязана к его бывшему уровню 5-летней давности. Изменить такую устоявшуюся систему крайне сложно из-за сопротивления изменениям и желания стабильности.

Компании на рынке могут сильно различаться. Кто-то ориентируется на hard skills, кто-то на soft skills, кто-то на бизнес-ценность.

Почему внутри одной компании возникают разногласия

Разберем ситуацию условного Middle-разработчика глазами трех ключевых сторон в компании.

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

Менеджер. Для него критично выполнение задач. Важно, чтобы Middle уверенно решал задачи средней сложности в срок и был командным игроком. Для менеджера Junior+ с горящими глазами и способностью к быстрому обучению может быть ценнее конфликтного Middle+. Ключевыми здесь является soft skills и командная работа.

Сам разработчик (Middle). Оценивает свой грейд по уровню знаний (hard skills). Он хочет решать сложные задачи, изучать новые технологии, развиваться. Зарплата важна, но не всегда основной мотиватор развития.

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

Мотивация

Главная опасность непрозрачных или неясных грейдов – чувство несправедливости.

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

Теория мотивации Герцберга (двухфакторная модель)

1. Гигиенические факторы. Наличие таких факторов закрывает потребности, а их отсутствие вызывает сильную демотивацию в работе. Пример: Зарплата. Если ее не хватает на базовые потребности (аренда, еда), человек быстро демотивируется и сменит место работы. Их наличие – это просто «норма», оно не мотивирует.

2. Мотивирующие факторы. Отсутствие факторов не демотивирует, но их наличие мотивирует. Пример: Похвала. Если не похвалили – ну и ладно. Похвалили – горы сверну.

Грейды и Пирамида потребностей (адаптация Маслоу + Герцберг)

Система грейдов сильно влияет на факторы всех уровней:

• Нижние уровни (желтый/красный). Ближе к гигиеническим факторам (стабильность, справедливая оплата).

• Верхние уровни (зеленый/синий). Ближе к мотивирующим факторам (признание, рост, самореализация).

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

Опыт внедрения. Начало. Хаос договоренностей

Пока команда была маленькой (до 10 человек), мы условно договорились: кто сколько получает, кто «ведущий аналитик», кто Middle/Junior/Senior. Однако такая система была крайне неустойчива. С ростом команды и введением формальной системы мотивации потребовалась структура.

Первая попытка. Красиво, но сложно

При введении формальной системы грейдов мы сели и договорились, что для нашей IT-компании важны:

1. Профессиональные компетенции (сертификаты, знание предметной области);

2. Маркетинговая активность;

3. Тиражируемость знаний;

4. Коммуникационные компетенции (soft skills);

5. Опыт работы;

6. Выработка (за последний период);

7. Оценка качества (360 градусов: команда, руководители, заказчики).

Создали цветную таблицу с ранжированием пунктов (красные – ключевые, черные – менее важные). Обнаружились проблемы:

• Неясность критериев. Как выбирать 5 из 10? Разработчики перестали расти, так как не понимали лестницу.

• Барьер сертификатов. Экзамены по типу ЭТВ оказались очень сложными (один сдавший за 6 лет в департаменте).

Вторая итерация. Четче, но без разработчиков

Вместе с менеджерами проектов мы разработали новую карьерную лестницу - Лестницу развития. Задача была сделать ее понятной, визуально оформленной и исключающей двоякие толкования. Разработчики помогли нам доработать концепцию. Были добавлены элементы управления проектами: Scrum, Kanban, а также практики наставничества и преподавания – важные для нас пункты.

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

Проблемой масштаба стало ведение индивидуального плана развития (ИПР) в Excel-таблицах по каждому сотруднику. Лестница превратилась в гору таблиц Excel.

Еще одна проблема, с которой мы столкнулись – некоторые обязательные пункты Лестницы развития стали «пропадать». Например, в описании грейда получение сертификата «Специалист» есть, а в ИПР сотрудника его может не быть.

Решение: Автоматизация в 1С:ЗУП КОРП. Мы перенесли всю систему грейдов в конфигурацию 1С:ЗУП КОРП.

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

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

Теперь все хранится в явном виде в системе документооборота. Вся история изменений записывается. Очень удобно.

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

Третья итерация. Вовлекаем экспертов

Осознав ошибку, начали их активно привлекать. Результаты:

1. Унификация языка. Создали глоссарий, согласовав термины (Junior, Middle, Middle+, Senior).

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

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

Итоги

1. Система грейдов – критически важна. Она затрагивает множество аспектов работы и мотивации.

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

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.