От стажера до эксперта #3: Матрица компетенций разработчика 1С

• Виталий Анянов, ведущий разработчик и руководитель проектного отдела компании.  

• Доклад посвящен финансовой мотивации и матрице компетенций в компании.  

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

• Компания является крупным интегратором с более чем 300 сотрудниками, из которых 70 разработчиков.  

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

• Компания активно сотрудничает с вузами и запускает стажерские программы.  

• Разработана программа обучения и развития разработчиков с нуля.  

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

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

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

• В компании придерживаются принципов нефинансовой мотивации и системы грейдов.  

• Важно, чтобы финансовая мотивация напрямую влияла на доход разработчиков.  

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

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

• В компании уже существует система грейдов, но она требует доработки.  

• Создан экспертный совет для разработки новой системы мотивации.  

• Использовано дерево развития разработчика, переложенное в формат таблицы.  

• Введены критерии оценки: скорость разработки, план-факт, качество кода и дисциплина самотестирования.  

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

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

• Цели: разработчики должны выполнять цели, такие как закрытие плановых часов по обменам или ПСКД.  

• В поддержке нет столько разработки, но компетенции важны.  

• Цели ставятся в зависимости от проектов и текущей обстановки.  

• В системе заявок добавлены теги для задач, что помогает отслеживать компетенции.  

• Качество кода оценивается ведущими разработчиками.  

• Оценка: 0 баллов - каждая задача требует рецензирования, 1 балл - половина задач проходит в тест, 2 балла - только большие задачи требуют рецензирования, 3 балла - разработчик может сам рецензировать код.  

• Разработчики должны знать предметную область для решения задач.  

• Сертификаты 1С помогают оценить знания в предметной области.  

• Сертификаты требуют серьезной подготовки и повышают стоимость разработчика.  

• Личная эффективность не всегда понятна для проверки.  

• Взаимодействие с командой стало важным блоком оценки.  

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

• В компании действует система наставничества, где обучением разработчиков занимаются другие разработчики.  

• Обучение оплачивается отдельно, включая участие в вебинарах и конференциях.  

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

• Ведущие разработчики сильно нагружены управлением разработкой и рецензированием.  

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

• Оценка ведущих разработчиков проводится как сверху, так и снизу.  

• Оценка ведущих разработчиков проводится по завершении проекта или с определенной периодичностью.  

• Разработчики оценивают своих ведущих разработчиков.  

• Система грейдов включает пять баллов, но не все навыки можно полностью освоить.  

• Разработчики определяют свои цели и задачи на основе интересов и проектов.  

• Система мотивации стимулирует разработчиков развиваться и выполнять цели.  

• Привязка к грейдам позволяет менять ставки и делать индексацию.  

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

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

• Система не всегда хорошо оценивает софт скилы, но технические скилы оцениваются и ставятся цели.  

• Планируется пересмотреть баланс и количество баллов за компетенции.  

• Возможно, появятся отдельные блоки для каждого отдела.  

• Система грейдов будет развиваться и улучшаться.  

• Обсуждение окладной системы мотивации и её преимуществ.  

• Вопросы от коллег о процессе лицензирования кода и работы с ответами.  

• Ответы на вопросы о лицензировании и тестировании кода.  

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

• Большие задачи декомпозируются на более мелкие, чтобы упростить управление.  

• Если задача сложная, она также разбивается на более мелкие части.  

• Баллы корректируются, но оклад остается прежним.  

• Если разработчик получает плохую оценку, его повышение откладывается.  

• В случае повторяющихся плохих оценок, возможно, стоит расстаться с сотрудником.  

• Допуск к выполнению работ на основе компетенций не используется.  

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

• Команды обычно состоят из 3-5 человек, что упрощает распределение задач.  

• Софт-скиллы не проверяются на грейдах 4-5, кроме оценки от аналитиков.  

• Цели на прокачку софт-скиллов ставятся, но проверка и цели пока не отработаны.  

• Оценка разработчиков и руководителей проводится раз в год.  

• Узкие специалисты и многостаночники могут иметь одинаковый балл.  

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

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