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

    
 
 Дисклеймер: якщо після прочитання цього тексту ви захочете впровадити KPI для програмістів — сходіть прочитати ще і це .
 
Нещодавно я писав про те, як були придумані карти компетенції і як ми застосовуємо їх на стажерів. Самі карти були придумані в допомогу для атестації програмістів. Сама атестація — справа складна, тоскне, і часто — невдячна.
 
Отже, які цілі переслідує атестація.
 
 Цілі
 
     
  • Подивитися поточний рівень розробника.
  •  
  • Дізнатися, які напрямки людині цікаво розвивати.
  •  
  • Надати можливість розвитку в тому ж технологічному векторі, в якому йде Сібірікс, або у факультативному напрямку (для загального розвитку).
  •  
  • Дати розробнику зворотний зв'язок: позитивну, або негативну.
  •  
  • Дати рекомендації: що краще прокачати, що потрібно підтягнути, що можна почитати.
  •  
 Рішення
Для того, щоб вся схема працювала, ми розробили і впровадили таку модель атестації:
 
 Крок 1. Заповнення карти компетенції . Перед атестацією її заповнює кожен розробник. Якщо будете впроваджувати, обов'язкова вимога — зробити заповнення карти компетенції регулярним.
 
 Крок 2. Сама атестація. Завжди відбувається один на один з розробником.
 
Ми розмовляємо і порівнюємо карти компетенції: поточну і попередні. Так можна відстежити прогрес і зміну орієнтирів конкретної людини.
 
Далі — аналізуються потреби (технологічні «хотілки») розробника. Для того, щоб допомогти прокачати якусь технологію, студія може запропонувати три варіанти:
 
     
  • перше і найголовніших — спробувати ставити людину на реальний бойовий проект з подібною технологією, коли (і якщо) так випадуть зірки.
  •  
  • Вивчити факультативно. Тут два варіанти. Переважний — влаштувати хакатон, так виходить більше практичних знань (так ми зробили Whoision , на хвилинку). Альтернативний — провести холівар по темі , а розробника призначити доповідачем.
  •  
  • Вивчити самостійно. Тут все в руках самого програміста, допомогти можемо рекомендаціями, що почитати, з ким у студії поговорити і можемо повірити знання.
  •  
У зв'язку з останнім в карту компетенції зараз додали список літератури: книг, без розуміння яких «крутим» себе вважати навряд чи можна. Ну або, принаймні, вони сильно прискорюють процес нарощення крутизни.
 
 Крок 3. Кодревью. Мною отсматрівать код програміста — реальні проекти, над якими він працював в останні півроку.
 
Зовсім не факт, що кодревью виявить якісь глибинні помилки. Для цього потрібно дуже багато часу. Воно спрямоване, швидше, на формування загального уявлення про рівень розробника. Таке знання стане в нагоді при формуванні команд (досвідчені / новачки) і при розподілі завдань усередині команди.
 

 «Talk is cheap. Show me the code ». Linus Torvalds
 

 Крок 4. Підведення підсумків. В результаті розробник отримує три цінних директиви: що почитати, що підтягнути, що спробувати з нового.
 
Наприклад, в ході однієї з атестацій ми з розробником вирішили, що йому потрібно прокачатися в Лінуксі. У підсумку знесли на його робочій машині вінду.
 
 
Знахідка: в ході атестації ми також застосовуємо варіацію відомого «методу 360 градусів». Ми розмовляємо з людиною, просимо розповісти про конкретних людей, з якими він працював, їх сильних і слабких сторонах. Так як в скрам всі проекти робляться в невеликих командах, то такий «інсайдер» може дати найбільш цінні рекомендації.
Чого немає в нашій системі атестації — так це бальної системи та іншої формалістики.
 
 Разом. Складнощі впровадження
Якщо ви захочете впровадити у себе щось подібне, то будьте готові як мінімум до трьох труднощам:
 
     
  • Це забирає дуже багато часу.
  •  
  • Не кожному керівнику хочеться цим займатися: говорити, з'ясовувати і уточнювати, щоб не було непорозумінь і недомовок.
  •  
  • Поради, які ви даєте за підсумками атестації — це і просто рекомендації, і імперативні вказівки із занесенням в персональний план і контролем виконання.
  •  
Колись давно я писав про виведення KPI для різних фахівців, текст все ще дуже актуальний, можете приєднуватися до дискусії, якщо що. А якщо ліниво читати, то висновок там був цілком однозначний: KPI для розробників — не працює. Але якийсь вимірювач все одно бути повинен — в нашому випадку це атестації.
 
 Мета атестації: не судити розробника, а допомогти йому рости. За результатами пари успішних атестацій у розробника може трапитися апгрейд зарплати. По-хорошому, атестацію потрібно проводити регулярно (пару раз на рік).
 
Думки і зауваження пропоную сміливо висловлювати нижче, із задоволенням послухаю і відповім!
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.