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

Меня зовут Виталий Онянов. Я работаю ведущим разработчиком 1С, и являюсь руководителем разработчиков 1С проектного отдела компании ФТО. Мы занимаемся внедрением и поддержкой информационных систем.

Хочу продолжить начатую два года назад серию докладов «От стажера до эксперта», где я рассказывал о нашем опыте управления, развития и обучения разработчиков 1С.

Ссылки:

• От стажера до эксперта
• От стажера до эксперта: развиваем команду разработчиков

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

Хотел бы сразу сказать, что это не будет какая-то история типа «смотрите, какую штуку мы сделали, она крутая получилась, используйте ее тоже». Это будет, скорее, история про то, что мы хотели сделать, что получилось, а что нет. Плюс какие-то мои личные мысли на эту тему.

Для тех кому удобнее смотреть видеоверсию доклада, вот вам:

Ну а тем кто остался, приятного прочтения. =)

О компании

Прежде всего хочу немного рассказать о структуре компании ФТО, чтобы был понятен контекст, в котором мы находимся.

• Компания ФТО – крупный интегратор. Количество сотрудников перевалило уже за 300 человек.

• Из них разработчиков 1С, по последней переписи, 70 человек, не считая довольно большого количества декретниц.

• Разработчики в нашей компании работают совместно с аналитиками.

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

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

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

Все это вынудило нас в свое время разработать некоторую программу обучения разработчиков 1С "с нуля". При этом мы не ограничились студентами, а разработали некую программу развития разработчиков, которая актуальна практически на протяжении всего пути работы разработчика 1С.

Результатом этой работы стало некое «Дерево развития разработчика 1С» – перечень необходимых разработчику компетенций с привязкой к различным учебным курсам, каким-то источникам знаний.

Дерево развития разработчика 1С

Подробно про это дерево и путь Джедая разработчика 1С я рассказывал в докладе на Infostart Event в 2018 году. В докладе можно подробно про это дерево посмотреть.

Если говорить вкратце, то мы выделяем четыре области развития разработчика:

• навыки разработчика 1С – его умение программировать;

• знание предметной области;

• на каком-то этапе, когда разработчик становится ведущим, ему будут необходимы функции управления, взаимодействия с командой, управления разработкой;

• и не забываем про личную эффективность.

К каждой из этих областей в дереве у нас есть детальные расшифровки, в докладе я про это рассказывал. Самое главное, что у нас после создания этого дерева появилось понимание, какие в принципе навыки нужны разработчику 1С. Кроме того, у нас накопилась некоторая база по источникам этих знаний – курсы, книги, что-то еще.

КАК развивать разработчиков 1С? Внедрение системы грейдов

Что развивать, мы поняли. Но если дать ребенку учебник, он не станет от этого умнее. И не надо думать, что все разработчики 1С целеустремленные, постоянно учатся, дай им только учебную программу, и они кинутся ее сразу изучать. Умом они, может быть, и понимают, что нужно постоянно учиться, но на практике, к сожалению, все немного не так.

О том, что мы делаем, чтобы процесс обучения у нас в компании не стоял на месте, чтобы люди были мотивированы развиваться, чтобы, по возможности, у них не было никаких препятствий в этом вопросе, я рассказывал в докладе на Infostart Event в 2019 году.

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

• примеры нефинансовой мотивации;

• систему грейдов;

• рассказал про постановку целей;

• контроль выполнения целей;

• обязательные встречи 1 на 1 и т.д.

Таким образом, мы разобрались:

• ЧТО развивать в разработчиках 1С;

• КАК это делать.

Но остался нерешенным самый главный вопрос – вопрос финансовой мотивации.

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

Финансовая мотивация разработчиков 1С

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

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

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

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

4. Наша система обязательно должна стимулировать на развитие. Причем, это должно быть что-то большее, чем просто ежегодное performance review. Мы не можем ждать год, чтобы дать сотруднику обратную связь и рассказать ему о результатах его работы – система должна быть более оперативна.

5. Система должна отвечать ценностям и каким-то сложившимся правилам компании ФТО. Мы на рынке с 2003 года, у нас уже сложилась какая-то система мотивации, и сотрудники к ней привыкли. Намерения и возможности ее менять у нас не было. Например, была система грейдов. И кроме того, у нас в компании всегда была строго окладная система мотивации: т.е. сотрудники у нас получают только оклад, и из-за переработок возможны премии, которые тоже зависят от окладов. И позиция нашего руководства всегда была и остается однозначной: окладную систему мы оставляем и менять ее не будем.

6. Последний, довольно тяжелый момент – система должна быть единой для всех отделов компании ФТО. Дело в том, что у нас много различных отделов:

   • Есть проектный отдел – мы приходим, внедряем какое-то решение у клиента, разработчики в основном занимаются потоковой разработкой, мы здесь следим за выработкой, за показателем план-факт, за сроками.

   • Есть отдел поддержки, там немного другая специфика, там разработки немного, а много консультаций, исправлений ошибок, обновлений релизов. Тот же самый показатель план-факт здесь не подойдет, потому что разработчик может два дня просидеть в отладчике и подправить две строчки кода. Здесь у нас главное – уровень удовлетворенности заказчика, соблюдение SLA.

   • Есть еще группа развития – это что-то среднее между этими двумя отделами.

   • Иногда продаем наших разработчиков на аутстафф.

   • Кроме этого, есть и другие направления.

   • Плюс разработчики могут переходить между отделами как насовсем, так и временно - поэтому систему мы хотели сделать единую.

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

Система грейдов

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

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

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

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

После чего мы для каждой строки этого дерева выписали необходимые компетенции которые необходимо прокачивать. А область «Администрирование» и «Технологические вопросы» мы выделили в отдельные группы.

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

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

Например:

• за навык работы с интерфейсом, знание СКД и за сертификат «1С:Специалист по платформе 1С» мы даем 2 балла;

• за все остальные навыки – по 1 баллу.

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

Далее мы начали продумывать, по каким критериям в принципе оценивать разработчиков? Как понять, что один разработчик плохой, а другой – нет?

Мы сформировали определенные требования, после чего в таблицу вошли еще такие строки, как:

• скорость разработки, план-факт;

• качество кода;

• дисциплина самотестирования;

• и такой субъективный параметр, как «Можно поручить задачу любой сложности».

Теперь осталось только понять, как проверять каждую из полученных компетенций, чтобы остался тот самый «принцип прозрачности» – чтобы сотрудник пришел к нам и спросил: «Что мне нужно сделать, чтобы подтвердить этот навык?», а мы ему дали абсолютно точный ответ.

Проверка навыков

Как я говорил, для очень многих навыков у нас были и есть учебные курсы – и наши внутренние, и внешние, и какие-то купленные, например, курс по запросам, по СКД, по правам доступа RLS. И мы решили их использовать. Надо пройти курс, сделать все практические задания, защитить экзамен, если он есть, получить диплом.

• За прохождение курса мы даем половину балла.

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

То есть прошел курс – хорошо, полбалла взял, а теперь подтверди своими задачами, что ты умеешь. И тут мы можем на встрече 1 на 1 поставить разработчику некоторую цель, например, закрыть 200 плановых часов по обменам или по СКД (в зависимости от навыка).

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

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

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

Как я сказал, в проектной деятельности я часто ставлю просто количество закрытых часов – например, закрыть 200 плановых часов на обменах через «Конвертацию данных 2.0».

Технически мы эту проблему решили следующим образом: в нашей системе заявок (в проектах у нас используется Redmine) мы добавили возможность для каждой задачи указывать тег (из списка выпадающих тегов). А теги, конечно, пришли из таблицы.

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

У Redmine есть довольно хороший API, мы сделали интеграцию с ним и уже собираем некоторую статистику в своей базе данных 1С, где мы можем смотреть:

• выработку по план-факту;

• кто с каким консультантом и с какой производительностью работает;

• на каких проектах и с какой производительностью работает;

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

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

В общем, очень интересная статистика в итоге получилась.

Субъективные навыки

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

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

• 0 баллов – когда каждую задачу нужно рецензировать, и большинство задач уходит на доработку;

• 1 балл – когда половина задач проходит сразу же в тест после рецензирования;

• 2 балла – когда только какие-то самые большие задачи необходимо рецензировать;

• 3 балла – это уже опытный разработчик, который может сам рецензировать код, проводить code review.

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

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

Проверка знаний предметной области – сертификаты 1С

Чуть сложнее у нас пошло с предметной областью.

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

То же самое и в поддержке – очень нужны знания предметной области, чтобы быстрее закрывать задачи.

Но как проверить эти знания – не очень понятно.

Например, у нас в проектах разработчик может закрыть 500 или даже 1000 часов на задачах в какой-нибудь 1С:ERP, где будет и блок торговли, и блок управленческого учета, и регламентированный учет, и даже производство. Вот он закрыл 1000 часов, а предметную область так и не выучил, потому что он занимался либо обменами, либо просто доработкой типового или не типового функционала (свои документы/регистры создавал), либо на отчетах просидел… То есть в принципе не совсем понятно, чем он занимался – изучил он предметную область или нет.

Устраивать разработчику экзамен – не вариант. Ведь для экзамена надо придумать какие-то вопросы, и принимать его должен более опытный человек.

Тут нам на выручку приходят сертификаты 1С по различным областям учета. Конечно, можно подискутировать на тему того, насколько реально вообще сертификат 1С отражает знания в предметной области. Лично я считаю, что более-менее отражает.

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

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

С сертификатами у нас только одна беда. Дело в том, что получение сертификата не сильно укладывается в текущую работу, и приходится готовиться в свое личное время либо урывками на работе. За счет этого цели по сертификации у нас выполняются не очень хорошо, а проверять предметные знания как-то иначе мы еще не очень умеем.

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

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

Проверка навыка взаимодействия с командой – обратная связь от аналитиков

Далее у нас был пункт про личную эффективность. Но опять-таки – как проверять личную эффективность, не очень понятно.

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

Поэтому мы подумали – что нам действительно важно? И вместо личной эффективности мы добавили блок «Взаимодействие с командой».

Это одна из немногих переменных оценок, которая может меняться. Потому что нам очень важна обратная связь от нашего единственного внутреннего заказчика – это аналитики 1С, которые ставят задачи, принимают задачи, тестируют их и т.д.

Вообще, в ценностях нашей компании – это то, что с любым сотрудником, вне зависимости от его должности и опытности, должно быть комфортно и легко общаться. Поэтому мы добавили соответствующие компетенции со стоимостью 3 балла. Хотя сейчас есть подозрение, что 3 балла – мало.

Как мы собираем обратную связь? Мы написали простые вопросы о работе разработчика и просим аналитиков периодически оценивать разработчиков, с которыми они работают. Это такой внутренний Net promoter score, где по пятибалльной системе мы оцениваем каждый навык.

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

На самом деле это очень хороший инструмент, как нам кажется. Он заставляет разработчиков более серьезно относиться к своей работе, более тщательно тестировать свои задачи, заботиться о том, что о нем думают, иногда даже где-то сдерживать свои эмоции.

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

Но как я сказал, у нас есть понимание, что 3 балла для навыка взаимодействовать с командой, наверное, маловато, и надо вес этой компетенции увеличивать.

Обучение и наставничество

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

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

Навыки управления

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

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

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

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

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

Причем, мы делаем оценку сверху – опрашиваем ключевых специалистов клиентов, PM-менеджера, функционального координатора, владельца продукта, если он есть.

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

Итоговая таблица оценки специалиста по грейдам

В итоге у нас получилась вот такая табличка.

Стоимость грейда у нас получилась 5 баллов, а всего 70 баллов.

Максимальный – 15-ый грейд, но это не совсем так. Невозможно прокачаться во всех отраслях: быть и экспертом, и предметную область знать, и командами управлять, и обучать.

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

Вот такая система. Выглядит неплохо, как нам кажется.

Выводы

Данную систему мы используем уже больше года. И за это время можно подвести некоторые итоги.

Начну очень оптимистично:

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

2. В целом сотрудники довольно хорошо приняли систему. Хочется, конечно, надеяться и верить, что это благодаря тому, что она прозрачна, безопасна и справедлива или смотри пункт 1.

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

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

5. Данная система очень хорошо работает где-то до 5-6 грейда, там вообще никаких проблем нет. Что нужно разработчику до 5-6 грейда? Ему нужно изучать новые компетенции, разрабатывать, желательно получше и побыстрее, ему нужно брать самые разнообразные задачи, чтобы все попробовать, ему нужно посмотреть курсы, налаживать контакты с аналитиками и так далее. И цели у них очень понятные, они дают очень быстрый эффект – посмотрел курс, выполнил какие-то задачи, навык получил.

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

1. Дело в том, что сильные разработчики у нас довольно сильно загружены – даже если они не работают ведущими, то все равно у них есть какая-то дополнительная активность, на них ставятся самые сложные задачи, у них физически не остается ресурса выполнять еще какие-то цели, которые лежат вне работы. А поставить цели, которые полностью в рамках работы, у нас не всегда получается, либо, может быть, мы просто не умеем пока этого делать. Нам тут тоже есть, над чем подумать. Кроме того, с новыми сотрудниками иногда бывают проблемы. Не секрет, что мы можем принять сотрудника на работу чуть выше стоимости по рынку. Но потом, когда кончится испытательный срок, мы делаем ему ввод по таблице грейдов, и разработчик может уйти на более низкий грейд. Потому что на собеседовании у нас была необходимость срочно взять разработчика, и мы его взяли авансом. Кроме того, за три месяца испытательного срока не все навыки можно проверить, и для некоторых навыков приходится верить на слово.

2. Еще наша система не очень хорошо оценивает софт-скилы разработчиков и такие переменные поля, как вклад в работу, отношение к работе. У нас есть выработка, план-факт, взаимодействие в команде, мы опросники делаем. Но если технические скилы мы научились оценивать, ставить цели, тут все хорошо, то с софт-скилами у нас пока есть еще некоторые проблемы. Тут мы ещё находимся в поиске каких-то оптимальных целей, оптимальных решений.

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

4. Кроме того, люди сразу видят, что они работают на неперспективных проектах. К сожалению, у нас есть поддержки, где самописные конфигурации, какие-то старые «КА1.1», «УПП» и даже проекты на УПП мы еще делаем. И разработчики очень хорошо чувствуют, что текущие задачи в таблицу грейдов, в их рост не ложатся. И мотивировать их работать на таких проектах становится все тяжелее и тяжелее.

В общем, и плюсов, и минусов – хватает.

Планы

У нас в планах:

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

• Обязательно научиться оценивать софт-скилы и ставить цели на достижение этих софт-скилов.

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

• В планах развивать систему и дальше – пока она нам нравится, мы ею пользуемся. Надо только кое-что чуть-чуть улучшить.

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

Вопросы

Честно скажу, ты немного порвал шаблон. С одной стороны, ты сказал, что система мотивации должна быть безопасной, должна стимулировать, должна мотивировать на рост. И тут же говоришь, что у вас оклад. Как оклад может стимулировать на рост?

Вполне нормально. Раньше я был противником окладной системы. Я говорил, что должна быть окладно-премиальная часть, что каждый должен зарабатывать столько, сколько ему надо. Но потом я почитал разные книжки по управлению, пообщался с людьми, и понял, что мой тип – предпринимательский, я готов работать усерднее, лучше, чтобы это сразу отражалось. Но оказывается, в России таких людей только 4%, а большинство людей хочет стабильности, хочет спокойствия, хочет не думать о том, сколько они просидели над задачами и сколько денег за это получат. Это вгоняет их в стресс.

И поэтому теперь я считаю, что окладная система не такая уж и плохая. У нас люди могут работать на качество, а не на результат. Это первое.

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

Как мотивировать? Мы вводим системы грейдов, ставим цели. Люди цели выполняют, переходят на следующий грейд, у них оклад растет. Ну а если вдруг у человека снижается эффективность, надо разбираться, что случилось. Для этого есть встречи 1 на 1, мы выясняем вовлеченность в работу, переводим между отделами, между проектами.

Как организован процесс рецензирования кода и работа с ответами?

Через трекер. Каждую задачу, которую разработчик сделал, он переводит на своего ведущего разработчика в статусе «На рецензирование». Разработчик накапливает эти задачи, обычно тестовую базу мы обновляем 2-3 раза в день, тимлид просматривает весь новый код, обновляет базу. Если есть доработки, отправляет на доработку, совместно разбирает. Если это удаленная работа, звонит, делает демонстрацию экрана, мы сидим, разбираем, в чем код неправильный. Если все ок, после обновления теста переводим задачу в тестирование. Мы это делаем через хранилище конфигурации.

Вы пушите изменения в конфигурацию большими блоками или маленькими частями?

Мы стараемся все-таки задачки брать поменьше. То есть у нас есть некоторые правила разбивки задач, и большие задачи мы стараемся декомпозировать. Максимум, наверное, 40 часов, больше 40 часов задачу точно не надо ставить. Потому что она будет бесконечно крутиться в трекере. Если это документ, то отдельно форма, отдельно проведение, отдельно печатная форма, отдельно заполнение табличной части, если он какой-то хитрый. Стараемся декомпозировать по возможности.

А в меньшую сторону вы баллы корректируете?

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

Не думали ли вы вводить допуск к выполнению работ на основе компетенций?

Нет, потому что распределением работ занимается ведущий разработчик. У нас команды обычно по 3-4-5 человек, редко по 9-10 человек. И ведущий разработчик более-менее представляет компетенции своих специалистов. Все задачи ставятся на него, и после оценки и вычитки задания на адекватность, он уже примерно в голове может представить, кто из его команды может справиться. Поэтому пока такой проблемы у нас не было.

Судя по всему, у вас слишком маленький вклад в софт-скилы.

Да, я же говорю, что мы не умеем их проверять. Мы сами это понимаем. На софт-скилы до 4-5 грейда мы особо не обращаем внимания, за исключением оценки от аналитиков, и ставим цели именно на прокачку. А потом у нас есть некоторые проблемы, согласен. Мы хотим больше софт-скилов, но мы не умеем их проверять, не умеем ставить цели.

Кто у вас занимается оценкой 360, как физически устроен процесс?

Сбором оценки для разработчиков занимаюсь я. А ведущих разработчиков и руководителей оценивают HR. То есть каждый руководитель либо ведущий разработчик раз в год получает полностью оценку 360 от коллег, от смежных специалистов, от руководителя, от тех, с кем он взаимодействует. Этим занимаются HR-менеджеры, они же проводят встречи по этой оценке. А по разработчикам, которые в команде, провожу лично я. Это просто опросник в Google, который я кидаю аналитикам, смотрю, с кем они работали по нашей системе, и вывожу какой-то итог, который мы с каждым разработчиком на встрече 1 на 1 обсуждаем.

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

Мы стараемся, чтобы узких специалистов у нас не было. Даже если есть узкий специалист, и горит задача под его компетенции, а он занят на другом проекте, его тимлид никогда не отдаст. Поэтому не могу сказать, что у нас много таких ситуаций. У нас есть специалисты, которые уходят в проектную область, они очень хорошо знают учет и могут с аналитиками вместе работать. Есть специалисты, которые уходят в производительность, сдают на экспертов, всем этим занимаются. А в остальном я бы не сказал, что у нас у кого-то узкие навыки – мне кажется, что в разработке все сильны.

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Оценка компетенций специалистов".