Аттестация программистов: наш опыт



    Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.

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

    Итак, какие цели преследует аттестация.

    Цели


    • Посмотреть текущий уровень разработчика.
    • Узнать, какие направления человеку интересно развивать.
    • Предоставить возможность развития в том же технологическом векторе, в котором идет Сибирикс, или в факультативном направлении (для общего развития).
    • Дать разработчику обратную связь: положительную, либо отрицательную.
    • Дать рекомендации: что лучше прокачать, что нужно подтянуть, что можно почитать.

    Решение


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

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

    Шаг 2. Сама аттестация. Всегда происходит один на один с разработчиком.

    Мы беседуем и сравниваем карты компетенции: текущую и предыдущие. Так можно отследить прогресс и смену ориентиров конкретного человека.

    Дальше — анализируются потребности (технологические «хотелки») разработчика. Для того, чтобы помочь прокачать какую-то технологию, студия может предложить три варианта:
    • Во-первых и самых главных — попробовать ставить человека на реальный боевой проект с подобной технологией, когда (и если) так выпадут звезды.
    • Изучить факультативно. Тут два варианта. Предпочтительный — устроить хакатон, так получается больше практических знаний (так мы сделали Whoision, на минутку). Альтернативный — провести холивар по теме, а разработчика назначить докладчиком.
    • Изучить самостоятельно. Тут все в руках самого программиста, помочь можем рекомендациями, что почитать, с кем в студии поговорить и можем поверить знания.

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

    Шаг 3. Кодревью. Мной отсматривается код программиста — реальные проекты, над которыми он работал в последние полгода.

    Совсем не факт, что кодревью выявит какие-то глубинные ошибки. Для этого нужно слишком много времени. Оно направлено, скорее, на формирование общего представления об уровне разработчика. Такое знание пригодится при формировании команд (опытные/новички) и при распределении задач внутри команды.


    «Talk is cheap. Show me the code».

    Linus Torvalds



    Шаг 4. Подведение итогов. В результате разработчик получает три ценных директивы: что почитать, что подтянуть, что попробовать из нового.

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

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

    Чего нет в нашей системе аттестации — так это балльной системы и прочей формалистики.

    Итого. Сложности внедрения


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

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

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

    Мысли и замечания предлагаю смело высказывать ниже, с удовольствием послушаю и отвечу!
    Сибирикс 65,81
    Компания
    Поделиться публикацией
    Комментарии 38
      0
      Довольно интересный подход!
      Мы у себя в компании делали чуть проще — рассылка по почте с небольшим количеством вопросов касательно интересующих технологий. По результатам составили план по проведению внутренних обучающих курсов.

      Ваш вариант в этом плане куда интереснее =)
        0
        А можно к вам прийти на собеседование? :)
          +3
          Можно. Записывай адрес: Сибирь, город Барнаул, Малахова 146В :)
            0
            Я знаю :) Я спрашивал, как и когда
              +1
              Напишите мне на job@sibirix.ru или постучитесь в скайп anna.kozhevina — согласуем дату и время. Как я понимаю — позиция php-программист?
              –1
              Кстати, когда был на собеседовании в 2ГИС, у них тоже было что-то похожее: список терминов и тем, которым надо было проставить оценки:
              1 — что-то слышал
              2 — могу объяснить, что это и как работает
              4 — знаю, умею, применял
                +1
                А что ставить, если применял, при необходимость, но сказать, что прям знаю и умею не могу? :)
                я бы в пункт 4 перенес из пункта 2.

                0 — что-то слышал.
                2 — применяю используя документашку.
                4 — знаю, умею, применяю.
                5 — все предыдущее и объяснить, что это и как работает.
                  +8
                  Ага…
                  7 — находил ошибки, отправлял патчи разработчику
                  10 — я и есть разработчик данной тулы
            +1
            Хуижин — мега-название, серьезно :)
              0
              Не собираетесь открывать филиал в Красноярске?
                +18
                Как человек, проходивший через подобные аттестации, могу сказать следующее.

                Заполнение карты компетенции — та еще муть. Зачастую там перечислены пункты, которые не то, что не имеют к тебе ну ни малейшего отношения, так и вообще с первого раза (и со второго тоже!) не понять, что это вообще такое. Я уж не говорю про то, что человек не в состоянии оценивать себя объективно, нужен взгляд со стороны, а то как-то забавно смотрятся карты вчерашнего студента, нарисовавшего себе ох какие знания в надежде получить повышение в деньгах. Абсолютно непонятно, зачем и кому (хотя кому — это понятно, толпы эйчаров и манагеров среднего звена создают видимость своей полезности в компании) это нужно. Ты тратишь целый день на эту лабуду, хотя прекрасно знаешь, что интересная тебе технология все равно в проекте применяться не будет. И на других проектах тоже не будет. А даже если и будет, то в другой проект тебя так просто не отпустят. А с какой стати отдавать человека, знакомого уже с проектом, в другую команду? Мы тебя, понимаешь, растили, учили, баги за тобой подтирали, а ты теперь свалить хочешь?!!! Учить тебе в рабочее время это тоже не нужно, потому что у нас есть Вася, который, если нужно будет, расшарит сои знания между всеми. Ну а пока время это не пришло, Вася пошлет тебя подальше с твоими расспросами, ибо ему и так есть чем заняться. Можешь доклад вот подготовить. Ага, ну очень полезная штука. Лично у меня все полученные на лекции знания выветриваются уже к следующей неделе. Потому как без практики все это баловство, а практика… смотри выше. Код ревью шняга тоже абсолютно бесполезная, ибо, не понимая детально требований, почерпнуть оттуда что-то полезное довольно сложно. Как и выдать замечания, отличные от «а чего это переменная названа так непонятно?». Так что остается самостоятельное изучение. В свободное время. А это самое свободное время у вас отбирают на всякие глупости вроде аттестации, которое лично вам ничего не дадут. Вот такое мое мнение обо всем этом.
                  –8
                  Вас видимо очень кто-то обидел. Все тлен, выхода нет, все дела.

                  Вы действительно хотели сказать, что в рабочее время, на работе, и на задачах, которые вам давала компания, с тем наставникам, которого вам дала компания, вы несмогли ничему научиться? Дуг мой, если это так — проблема в тебе самом.
                    +2
                    Конечно я научился чему-то в рабочее время на задачах и с наставниками компании. И могу утверждать, что мое «хочу» и компанейское «нужно» не имеют ничего общего. И не настолько наивен, чтобы думать, что подобные мероприятия имеют пользу для сотрудников. Студентов вы этим увлечете, да. В первые пол года. Потом и они поймут, что лучше день потратить на себя, чем на ерунду. Вот эйчарам польза — они смогут лапши на уши потенциальным кандидатам навесить на одну ложку больше: «вау как у нас круто, вы можете расти, работать над собой и совершенствоваться, у нас специальный патентованный инструмент для этого есть!!1». Манагеры среднего звена (скорее всего именно они и затеяли эту инициативу) довольны вдвойне — с одной стороны это возможность показать свою активность и пользу перед хозяином, с другой — лишний аргумент в отказе в повышении з/п: «ну и что, что вы, батенька, два года уже на проекте без повышения, вы на карту свою посмотрите, ай-яй-яй, а давайте ка вы для начала изучите вот это, вот это и последние восемь листов, а потом мы вернемся к вопросу повышения».

                    Отдельного разговора заслуживает сама карта. Таким сложнейшим вещам, как границы и отступы, посвящено всего два пункта. А таким мелочам, как СУБД, например, по целому одному пункту на каждую. Так и вижу заполненный лист: границы — «не, не слышал», а вот отступы — «профессионал!».

                    PS. Судя по тону ответа, удовольствие от моего комментария, получить которое вы обещались в конце статьи, не наступило.
                    Печально, что вместо дискуссии, вместо попытки обсуждения каждого из пунктов поста, вы скатились в психоанализ и съехали с темы.
                    Впрочем, заглянув в ваш профиль и увидев слово «менеджер», стало понятно, что вы и есть тот самый представитель среднего звена, который сам толком не знает, как все это может быть полезно для подчиненных, но свято верит в необходимость. Ваше поведение полностью подтвердило мои слова.
                    Да и количество плюсов к моему комментарию и минусов вашему тоже как бы намекают, что думает народ. Так что вы можете сколько угодно сливать карму, это лишит возможности оставлять комментарии, но популярности картам компетенции не добавит.
                  –6
                  надо запомнить:
                  Владимир Завертайлов из Сибирикс.
                  Владимир Завертайлов из Сибирикс.
                  Владимир Завертайлов из Сибирикс.
                    0
                    Не очень понятно, какое отношение к backend-разработчику имеют первые 3-4 раздела.
                    Или это какая-то общая для всех анкета?
                      0
                      Это общая анкета.
                        0
                        Возможно ли, хотя бы теоретически, что backend-разработчик вдруг захочет развиваться в плане frontend'а?
                        Были ли случаи, когда бэкенд разработчик уходил во фронтэнд?

                        Каков состав разработчиков в качественном плане? Много ли джуниоров?
                      0
                      Что такое дисклеймер? Большой толковый словарь ничего не выдал www.gramota.ru/slovari/dic/?word=%C4%E8%F1%EA%EB%E5%E9%EC%E5%F0&all=x
                          –1
                          Википедию может заполнить любой желающий
                            +3
                            Эээээ…
                            Да…
                            И чо?
                              –1
                              Достоверность информации вызывает сомнения, не про конкретно данный случай, а в целом про источник.
                                +1
                                Поводов и причин для неправильного описания данного определения нет.
                                Вот если бы статья была какой-нибудь политической и т.п. то да.
                          0
                          Вы б ещё в словаре Даля поискали…
                            0
                            Со словарем Даля уже можно не считаться?
                              0
                              он не содержит современных англицизмов
                                –3
                                Почему бы не выражаться на родном русском языке? У нас же не англоговорящее общество.
                                  +2
                                  [занудаOn] начните с себя: аутстаффинг, «дресс код», [/занудаOff]
                                    –1
                                    Так в том то и проблема, что данные слова незаметно входят в лексикон.
                                0
                                Вам не кажется, что там может не оказаться современных юридических терминов? Учитывая, что он составлялся в 19 веке…
                            –2
                            Сама разумная оценка разработчика — это какую финансовую пользу он приносит компании. Причем рассматривать это нужно в долгосрочной и краткосрочной перспективе. А чтобы разработчик работал на свой максимум надо чтобы старого было легко уволить, а нового легко нанять.
                              +2
                              Сама разумная оценка разработчика — это какую финансовую пользу он приносит компании.
                              Есть работники и подразделения, которые не приносят явной пользы с точки зрения «эффективных менеджеров», но их отсутствие, как минимум, повышает риски. Те же сисадмины, которые при отсутствии серьезных изменений в условной компании выглядят бездельниками, их увольняют/замещают студентами-эникеями, после чего при любой более-менее серьезной проблеме несут серьезные убытки, несопоставимые с экономией на очередном «бездельнике».

                              А чтобы разработчик работал на свой максимум надо чтобы старого было легко уволить, а нового легко нанять.
                              Если говорить про разработчиков и админов среднего уровня и выше — то для нас (разработчиков и админов, как минимум) сейчас рынок работника, что несколько уменьшает количество «соковыжимателей» на рынке работодателей. Невозможно постоянно работать на максимуме — выгораешь. Бизнесу на это плевать, если он может быстро заменить человека, но в действительности, если говорить не про эникея/code monkey, то замена стоит дорого.
                                –2
                                Финансовая польза — это не живые деньги, которые текут от заказчика. Если при замене сисадмина на студента компания понесла убытки, то значит сисадмин приносил финансовую пользу :) А работа на максимуме не означает работа на выгорание. Скорее максимум — это выкладываться в компании без вреда своему физическому и психическому здоровью.
                              0
                              Мы проводим переаттестацию 2 раза в год. Это единственный возможный вариант изменения оклада, ну кроме форс-мажоров рынка. Специалист заполнят анкету, где есть 4 компетенции. Затем непосредственный начальник заполняет тоже самое. Затем анализ документов старшим и личная беседа, где задаются уточняющие вопросы и выносится решение по изменении грейда. Также составляется персональный план развития до следующей переаттестации.
                                0
                                Я вот не совсем понимаю смысл такой аттестации. По шагам:
                                1) Зачем в карте указывать список своих, хм, компетенций? С вероятностью чуть менее, чем 100%, в компании уже выбраны конкретные технологии/фреймворки и т.п. По сему, логичнее для работодателя ставить вопрос не «какие технологии и насколько хорошо вы знаете?», а «вам знакомы *название_технологий_использующихся_на_предприятии* и на сколько хорошо?»
                                2) «Хотелки» разработчика как правило в расчёт не берутся. Если он хочет изучить какую-то технологии/фреймворк, то должен это делать дома. Или же вы поощряете изучение новых технологий на своих проектах? Не думаю. На рабочих проектах необходимо использовать уже обкатанную, хорошо знакомую технологию.

                                  0
                                  Возможный рост сотрудника упирается только в технические скилы? Может ли сотрудник дорасти до руководителя команды? Проекта? Не вижу нигде софт-скилов.
                                    0
                                    Может дорасти и есть неоднократные истории. Но это отдельная тема.
                                      0
                                      Почему же отдельная? Сотрудник IT компании должен всесторонне развиваться, а только разбираться в HTML5 и верстке писем. А у вас получается, что системно можно развивать только техническую ветку.

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

                                  Самое читаемое