Mungkin saja Anda berkata: “Matriks kompetensi? Benarkah? ” Kemungkinan besar Anda sudah mendengar sesuatu tentang alat ini, dan bahkan membuat kesimpulan mengapa Anda tidak ingin menggunakannya. Mungkin itu tidak terjadi sebelumnya, atau bagaimana argumen pembunuhan "terjadi secara historis ...".

Sebenarnya, ini adalah alat yang sepenuhnya logis dan bukan alat baru yang bisa sangat berguna. Dan Anda dapat menerapkannya dengan cara yang sangat berbeda, yang kami akan coba buktikan kepada Anda dalam kasus praktis dari dua tim yang berbeda - dukungan teknis dan pengembangan. Berdasarkan pada mereka, Anda sendiri akan dapat memperkirakan biaya tenaga kerja (mereka bisa sangat berbeda) dan mencari cara yang lebih cocok untuk Anda dalam arah ini.

Dan apa hubungannya naga dengan itu, kami akan jelaskan di bawah potongan.



Artikel ini didasarkan pada artikel kami dengan Konstantin Kaftan di TeamLead Conf . Konstantin Timlid, Departemen Dukungan Teknis IPONWEB, dan saya adalah penulis teknis tim pengembangan di IPONWEB, yang terlibat dalam manajemen pengetahuan.

Cerita ini dibangun di atas kasus-kasus praktis IPONWEB, jadi pertama-tama kenali perusahaan sedikit sehingga Anda dapat memahami apakah materi ini dekat dengan Anda.

SDM kami, atas permintaan untuk gambaran pemasaran yang keren yang akan menceritakan tentang lingkup kami, memberikan ini:


Memang, IPONWEB mengembangkan platform untuk pelanggan yang terlibat dalam periklanan online. Kami sedang mengerjakan model Perangkat Lunak sebagai Layanan (atau lebih tepatnya Platform sebagai Layanan). Kami memiliki banyak komponen: server HTTP, algoritma prediksi, UI, pelaporan. Logika bisnis untuk sekitar 50 proyek ditulis dalam Lua.

Kami juga memiliki BidSwitch andalan, yang dimulai sebagai spin-off. Kami lebih tertarik pada integrasi mitra (sisi permintaan, sisi penawaran), jadi kami memiliki banyak log. Ini adalah proyek yang sama, pada tumpukan yang sama, tetapi cukup besar, ia memiliki spesifikasi dan jalur dukungan teknis khusus, yang dikepalai oleh Konstantin.

Mengapa kami memilih nama "Naga Tinggal Di Sini," apa artinya ini? Jadi sebelumnya pada peta abad pertengahan yang ditunjuk tempat-tempat di mana tidak diketahui apa yang terjadi - seperti Terra Incognita. Ada dua cerita tentang ini. Yang pertama adalah tentang struktur keterampilan dan keterampilan yang dimiliki tim, dan semakin besar tim, semakin banyak Terra Incognita yang ada; dan bicarakan yang kedua sesaat kemudian.

Bagaimana kita sampai di sini

Kebetulan kami (Svetlana dan Konstantin) tidak sering tumpang tindih dalam pekerjaan, dan bahwa kami hanya mengajukan aplikasi dengan materi yang sama hanya dari situs web konferensi . Kemudian kami memutuskan untuk bersatu - bagi kami tampaknya ini akan lebih menarik bagi semua orang.

Profil Tim

Tim Dukungan Teknis Konstantin:

• Jumlah karyawan: 10-12 orang.
• Jarak timlid: pendek - semuanya terlihat satu sama lain.
• Serangkaian keterampilan: serangkaian keterampilan, kompetensi, alat kerja yang sangat beragam - ini disebabkan oleh kenyataan bahwa kita memiliki cara untuk menarik tugas baru bagi kita dari kolega tim dan departemen lain.
• Gaya kerja: mencuri tugas dari rekan kerja. Ini dilakukan, pertama, untuk mencairkan dukungan rutin, oleh karena itu, tidak terlalu menarik untuk menganalisis jenis permintaan yang sama hari demi hari. Kedua, melihat siapa yang mendapatkan apa, dan menguraikan arah pembangunan.

Tim Pengembangan Lua Saya:

• Headcount: 40 orang, tetapi jumlahnya terus berubah;
• Jarak dengan pimpinan tim: cukup lama karena kekhasan struktur manajemen di perusahaan (itu adalah matriks). Artinya, pemimpin tim tidak melihat setiap pengembang setiap hari dan tidak tahu persis apa tugasnya sehari-hari.
• Perangkat keterampilan: kurang lebih seragam. Pengembang menulis logika bisnis dalam Lua, tetapi pada saat yang sama, mereka semua memasuki unit bisnis, yaitu dalam penyatuan proyek, misalnya, dengan apakah mereka menjual slot iklan atau membeli iklan sebagai pengiklan.
• Gaya kerja: tugas spesifik, faktor bus. Seringkali, pengetahuan terkonsentrasi di kepala individu, bukan seluruh tim dipertukarkan.

Deskripsi perintah diperlukan untuk memperjelas perbedaan implementasi matriks kami. Kami akan mencoba menggambarkan bagaimana tim yang berbeda menuju hal ini, apa yang terjadi pada akhirnya, karena struktur tim, pesan, tujuan, pemicu dan hasil akhir agak berbeda.

Tujuan dan Pemicu

Di tim Dukungan Teknis:

• Siapa yang melakukan apa? Itu perlu untuk mencari tahu ketika semuanya menjadi terlalu banyak, dan tidak lagi cocok di kepalaku, siapa yang melakukan apa, siapa dan apa yang mampu dan pada tingkat apa.
• Spesialis mana yang tidak ada? Akibatnya, siapa yang hilang untuk menyelesaikan tugas, siapa yang perlu dilatih.
• Kompetensi apa yang umum dan diperlukan untuk semua orang? Hal utama adalah memahami pada tahap seleksi apa yang umum dan wajib, apa yang perlu ditulis untuk SDM dalam profil kandidat yang ideal.

Di tim pengembangan, tujuan dan pemicu sedikit berbeda. Insentif awal adalah tepatnya manajemen pengetahuan, karena, sebagaimana telah disebutkan, kami memiliki bisnis yang sangat spesifik - Teknologi Iklan. Kemungkinan seseorang datang dengan pengetahuan siap pakai sangat rendah, dan pada saat yang sama, untuk pengembang, pengetahuan spesifik bisnis sangat penting.

Dalam Tim Dev itu perlu:

• Mempercepat pemula orientasi . Dimasukkannya jangka panjang pengembang dalam proyek ini sangat menyebalkan. Onboarding memakan waktu sekitar enam bulan, yaitu, lebih dari masa percobaan, yang berarti kami akan melatih pengembang dengan biaya kami sendiri.
• Memahami struktur pengetahuan, menilai kesenjangan dalam pengetahuan , menemukan titik putih, menguraikan rencana pelatihan, menguraikan jalur pertumbuhan individu.
• Karena struktur matriks, perlu untuk lebih merata mendistribusikan pengembang di antara unit bisnis dan tugas, dan tidak menyinggung siapa pun. Artinya, jangan mengirim semua senior ke satu unit bisnis.

Ada juga tujuan sampingan - untuk membuat proses peninjauan kinerja lebih transparan, dapat dipahami, untuk merumuskan tujuan dalam sistem koordinat tunggal.

Ulasan kinerja

Tinjauan kinerja adalah standar perusahaan kami. Sekali setiap N bulan, tinjauan kinerja dilakukan dengan setiap karyawan di hadapan karyawan, pemimpin timnya, menggunakan SDM atau notaris sebagai wasit. Pada tinjauan kinerja, kami memeriksa apa yang dilakukan karyawan dari tugas yang ditetapkan, apa yang tidak berhasil, jika tidak berhasil, mengapa, apa lagi yang ingin kami capai, apa yang bisa kami tawarkan. Setelah itu, tujuan dan sasaran baru ditetapkan, batas waktu berikutnya ditetapkan.

Dalam tim pendukung, periode ini cukup singkat, karena tidak ada proyek besar yang berjangka waktu - ini adalah 3, maksimum 4 bulan. Tim pengembangan memiliki siklus tinjauan semi-tahunan. Sebelumnya, tenggat waktu lebih lama, hanya karena pengembang dapat lebih baik menguraikan peta jalan. Dalam beberapa tim pengembangan lainnya, misalnya, tinjauan kinerja front-end juga terjadi setiap 3-4 bulan. Mungkin intervalnya tidak ada hubungannya dengan pengembangan atau dukungan tim, tetapi itu terjadi pada kami.

Mengapa Anda membutuhkan matriks kompetensi

Setahun yang lalu, perusahaan kami mengalami masa pertumbuhan yang intensif, ada lebih banyak orang, lebih banyak alat, lebih banyak tugas, lebih banyak. Pada satu titik, menjadi jelas bahwa tanpa dokumen yang tepat sulit untuk memahami apa yang terjadi. Dan kami menemukan solusi untuk mensistematisasikan informasi: tentang tugas; alat dan keterampilan; karyawan.

Mengapa Anda membutuhkan semua ini? Anda akan belajar tentang kasus-kasus praktis kami, tetapi Anda mungkin memiliki pertanyaan yang masuk akal - bagaimana memahami bahwa saya membutuhkannya?

Jika Anda memiliki masalah yang serupa dengan yang telah kami sebutkan di atas, yaitu, Anda tidak memahami kumpulan tugas pengembang Anda, terlalu lama memperkenalkan karyawan baru dan masalah lain yang telah disebutkan, maka Anda mungkin memerlukan ini.

Mulai dari mana

Di mana untuk memulai kita akan memberi tahu dengan contoh kita.

Dalam tim dukungan teknis, kami: mengidentifikasi tugas-tugas yang kami lakukan; tugas terurai menjadi manipulasi terpisah; menemukan alat apa yang harus diketahui karyawan untuk bekerja di sektor tertentu.

Di bawah ini adalah contoh yang sedikit disederhanakan.


Tim ini memiliki karyawan Batman, Joker, Flash dan Ivanov, dan tugas standar:

• diagnostik lalu lintas umum;
• diagnostik lalu lintas transaksi;
• pemantauan penyebaran;
• menguji integrasi mitra baru, baik DSP dan SSP, baik pembeli dan penjual.

Dari alat yang kami miliki:

• uSIicer memungkinkan Anda untuk mendapatkan angka perdagangan yang sangat rinci;
• Graphite menyediakan data status sistem waktu nyata;
• Google BigQuery (BQ) - log kami tinggal di sana;
• Grafana, yang memungkinkan Anda untuk mengumpulkan metrik dari Graphite, akan lebih mudah untuk memberi peringatan jika diperlukan;
• Penyesuaian ul pada antarmuka admin, yang memungkinkan Anda mengubah parameter lalu lintas untuk mitra tertentu, pasangan perdagangan, pusat data, dll.

Kemudian kami menemukan siapa yang tahu apa dan sampai sejauh mana.


2 - seorang ahli yang bisa mengajar; 1 - berarti seseorang tahu lebih banyak atau lebih sedikit; kosongkan sel saja, agar tidak menyinggung siapa pun.

Kami merangkum dalam satu tabel:


Alat-alat yang tidak diperlukan dalam tugas yang diberikan disorot dalam warna abu-abu. Misalnya, untuk diagnosis umum, kita tidak perlu tahu BQ dan Grafana. Hasilnya adalah gambar yang agak menarik.

Nezhdanchiki (Dukungan)

Beberapa orang tak terduga muncul yang membantu untuk memahami:

• Manakah dari kolega mana keterampilan yang harus ditarik untuk menarik mereka ke tugas-tugas baru? (Tunjukkan arah pembangunan);
• Di mana bisa timbul masalah jika kehilangan karyawan?
• Seberapa memadai gaji karyawan ke kumpulan tugasnya?
• Seberapa baik tim dikelola dan dilatih?

Kita akan membahas masing-masing poin nanti.

Ayo kembali ke meja.



Secara formal, Batman sibuk dengan diagnostik umum. Tabel tersebut menunjukkan bahwa Joker, jika perlu, akan menggantikannya dengan baik, mengingat fakta bahwa ia masih ahli dalam UI - mengapa tidak? Artinya, Batman bisa diganti di sini.

Pelawak itu umumnya dilakukan dengan baik - ia hampir paham di mana-mana, kecuali mungkin menggunakan pengawasan, tetapi ini bisa diajarkan.



Diketahui bahwa Joker menghabiskan waktu luangnya dengan agak eksentrik dan bisa keluar dari pekerjaan kapan saja. Lalu apa yang akan terjadi? Maka semuanya akan sedih dengan diagnosis lalu lintas kesepakatan.

Tidak hanya itu, kami tidak memiliki pakar BQ! Artinya, sangat mendesak untuk menarik seseorang, untuk melatih. Misalnya, Anda dapat mengajar Batman BQ, dan Ivanov - Graphite.



Bahkan dengan sistem penilaian yang disederhanakan, Anda bisa mendapatkan jumlah tertentu untuk setiap karyawan untuk memahami seberapa kompeten dan fasihnya dia. Perkiraan ini melemparkan hal lain yang tidak terduga.

Dua hal menarik lainnya adalah jumlah total tim dan skor rata-rata. Sebenarnya, angka-angka ini saja tidak terlalu menarik - dinamika perubahan mereka dari bulan ke bulan menarik. Jika karena alasan tertentu total mulai turun, maka kemungkinan besar seseorang pergi, dan karyawan yang lemah datang - masalah dengan konfigurasi, Anda perlu menghubungi SDM. Jika rata-rata mulai turun, itu berarti ada sesuatu yang salah dengan pelatihan - pemimpin tim dan hanya pemimpin tim yang harus disalahkan.

Penting bahwa dalam hal ini ini adalah alat pemimpin tim yang tidak diperlihatkan kepada karyawan, karena penilaian bersifat subyektif.

Tim pengembang

Semuanya sedikit lebih demokratis dalam Tim Dev, atau mungkin kita hanya mempersulit tugas kita. Daftar keterampilan dalam tim pengembangan lebih besar, meskipun keseragaman tugas mungkin lebih tinggi.

Kami mengumpulkan saran dari 4 pengembang berpengalaman (termasuk pemimpin tim dan spesialis manajemen pengetahuan), bertukar pikiran, dan menganalisis tugas dan keterampilan. Kami hanya berjalan selangkah demi selangkah dan pada perasaan pribadi kami, tetapi beberapa orang menganalisis tugas, meletakkannya berdasarkan keterampilan, membentuk daftar.

Pada awalnya itu daftar, kemudian disusun menjadi keterampilan yang lebih universal, yang mencakup pengkodean dan keterampilan bisnis terpisah, karena bagi pengembang kami ini adalah bagian penting. Dan dari daftar keterampilan ini sudah dibuat matriks.

Iterasi pertama dari matriks tidak termasuk yang disebut soft skill, yaitu, apa yang tidak bisa disebut hard skill. Ini adalah sesuatu yang berkaitan dengan pekerjaan sehari-hari, dan bahkan bagian dari keterampilan kritis, termasuk: perencanaan; komunikasi dengan tim; kemampuan untuk mengelola proses pengembangan dalam kelompok kecil atau sendiri; kemampuan untuk merumuskan persyaratan, misalnya, selama tinjauan kode.

Kami tidak segera memasukkan semua keterampilan ini, karena kami tidak mengerti bagaimana cara mengevaluasinya secara akurat.

Pada iterasi kedua, mereka memasuki sistem evaluasi:

• dekomposisi tugas dan segala sesuatu yang berkaitan dengannya;
• Dokumentasi dan kode dokumentasi diri
• kemampuan untuk berkomunikasi dengan manajer proyek, yaitu, untuk memahami apa yang dia katakan dan mengajukan pertanyaan yang diperlukan pada gilirannya;
• kemampuan untuk merumuskan komentar dengan benar pada ulasan kode, dll.

By the way, tentang soft skill dalam mendukung. Faktanya adalah bahwa soft skill dalam tim pengembangan memerlukan evaluasi terpisah. Namun, kualitas pribadi yang hanya diinginkan untuk pengembang untuk tim dukungan diperlukan . Jika seseorang dipekerjakan, maka dia sudah memilikinya secara default.

Dalam perkembangannya, kami meninggalkan konsep "soft skill", dan menyebutnya keterampilan universal. Mereka tidak memasukkan, misalnya, pengetahuan tentang bahasa Inggris atau fakta bahwa Anda tidak membuat marah tim Anda - ini bukan, karena itu hanya lebih dekat dengan soft skill, menggambarkan karakter seseorang. Kami mengevaluasi keterampilan di suatu tempat di ambang, dan karena itu muncul dengan nama seperti itu - keterampilan universal .

Ketika daftar keterampilan sudah siap, kami mengevaluasinya menggunakan survei berkelanjutan. Kami melakukan ujian nyata, di mana beberapa pertanyaan menyarankan jawaban yang pasti, dan beberapa membahas situasi kerja: "Apa yang harus saya lakukan jika seseorang menunda atau tidak melakukan sesuatu?", "Bagaimana Anda menerapkan fungsi ini atau itu dalam proyek?" . Ini sangat membantu kami, karena bagian dari pertanyaan ini memungkinkan saya untuk berbicara dengan sejumlah besar pengembang.

Kemudian kami menilai pengembang pada skala 1 hingga 3 untuk setiap keterampilan.

Keterampilan-keterampilan yang tidak dapat kami nilai dengan bantuan survei awal, kami evaluasi dengan bantuan teman sebaya (peer), yaitu, mereka diminta untuk mengevaluasi rekan kerja. Pada saat itu, kami tidak memiliki pemimpin kelompok, kalau tidak mereka bisa melakukannya.

Matriks ini terlihat seperti ini.



Tentu saja, tidak mungkin untuk memasukkan semua yang ada di gambar, jadi beberapa hal, misalnya, korelasi dan profil pengembang tidak jelas di sini. Namun demikian, Anda dapat secara kasar mengevaluasi apa yang terjadi, dan melihat seberapa jelas itu dan apa yang dapat Anda ukur.

Warna konsisten dengan grade. Metrik yang sama disimpulkan seperti dalam tim dukungan - total dan berbagai rata-rata dalam keterampilan.

Mari kita perhatikan Dev8. Dari tabel ternyata ini seolah-olah kandidat pertama untuk pemberhentian. Tapi, pertama, dia memiliki pengetahuan khusus di salah satu posisi, jadi kita membutuhkannya. Tetapi yang lebih penting, tabel ini bukan alat menembak . Saya juga akan memberi tahu tentang ini, kami tidak memulai semuanya hanya untuk itu.

Keterampilan rata-rata - ini adalah pekerjaan, yang hasilnya harus dibentuk rencana tentang cara mengencangkan keterampilan. Artinya, jika pengembang tidak tahu sesuatu, ini bukan masalah mereka. Ini berarti bahwa kami tidak memberi mereka informasi yang cukup, dan secara umum, pengetahuan tentang beberapa keterampilan umumnya tidak cukup di perusahaan. Anda perlu menulis dokumentasi, atau membuat semacam taman bermain sehingga mereka dapat berlatih, atau membeli semacam kursus eksternal sehingga mereka dapat belajar, melakukan Sesi Berbagi Pengetahuan, mengirim mereka untuk belajar dari satu sama lain, bekerja bersama untuk sementara waktu, termasuk orang dalam proyek lain. Mungkin ada opsi berbeda untuk berbagi pengetahuan. Intinya adalah bahwa Anda harus terlebih dahulu mengadakan acara, dan baru kemudian berbicara tentang dinamika.

Penting untuk dicatat bahwa karena perusahaan kami memiliki struktur matriks, tidak semua pengembang memerlukan keterampilan. Mereka akan menerimanya saat mereka menyelesaikan tugas yang terkait dengan keterampilan ini. Kalau tidak, tidak masuk akal, terutama jika keterampilan itu tidak termasuk dalam daftar kritis. Sebagai contoh, di beberapa bagian dari proyek tidak ada uPredict, ini bukan keterampilan kritis. Secara umum, pendekatan ini membantu kami untuk merumuskan keterampilan mana yang penting dan mana yang tidak, dan apa yang bisa dikejar oleh spesialis ketika ia memiliki tugas praktis seperti itu.

Poin penting lainnya tentang penilaian. Kami awalnya membuat kesalahan, yang memprovokasi lebih dari yang bisa ditoleransi tim - kami tidak mengucapkan secara verbal nilai peringkat 1, 2 dan 3. Mereka berada di kepala kami pada tingkat intuisi, tetapi kami tidak bisa menjawab mengapa satu pengembang mendapat 1, dan yang kedua - 2. Pengembang berbagi hasil penyebaran satu sama lain dan ini memicu konflik. Berbeda dengan kelompok pendukung, kami melaporkan peringkat pribadi berdasarkan permintaan, tetapi tidak untuk orang asing.

Anda perlu mendefinisikan dan meneruskan ini dengan jelas kepada semua orang, misalnya, bahwa dalam pengetahuan Lua nilainya adalah:

• 1 - artinya pengembang mengetahui semua operator dasar, tahu cara bekerja dengan struktur data dan menulis kelas fungsi;
• 2 - tahu cara mengatur kode ke perpustakaan, secara konsisten bekerja dengannya di seluruh proyek dan tahu apa itu metatables;
• 3 — , , ( Lua), C++ Lua-, , , , JIT-.

, - .

Note to self:

• , .
• . , , . , .

, . , .

, . A, B C — - junior, middle, senior. IT junior, middle, senior , , , . , . A, B C — . « » .

— .

, . , , , , .

, - , , . , , . , - — , , , .

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

Kasing

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

Dan itu saja! 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

• . , , , , .
• , - — . . , , .

, HR, , -, , -, , , -, HR - . HR , , .

• , .

-. . , , . , . — - , — . .

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .