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



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

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

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

    Цели


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

    Решение


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

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

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

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

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

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

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

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


    «Talk is cheap. Show me the code».

    Linus Torvalds



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

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

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

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

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


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

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

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

    Мысли и замечания предлагаю смело высказывать ниже, с удовольствием послушаю и отвечу!
    Сибирикс 67,31
    Компания
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 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 и верстке писем. А у вас получается, что системно можно развивать только техническую ветку.

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