Seorang karyawan yang tahu banyak, tahu bagaimana dan siap memadamkan api di padang rumputnya, tentu saja, dilakukan dengan baik. Tetapi jika pahlawan ini pergi berlibur atau bahkan berhenti, masa-masa sulit akan datang. Ternyata penting tidak hanya untuk tahu banyak, tetapi juga untuk dapat berbagi pengetahuan ini.
Aleksey Troshin (
morroz ) telah berkecimpung dalam profesi ini selama hampir 20 tahun, ia telah bekerja sebagai manajer Proyek dan Produk sejak tahun 2002. Selama masa ini, ia bekerja di berbagai perusahaan, memimpin tim dari 2 hingga 150 orang, dan sekarang mengelola pengembangan di FINAM. Di sini, Alex membangun sistem yang membantu tidak hanya untuk menyebarkan pengetahuan, tetapi juga untuk memotivasi pengembang untuk tumbuh dalam arah bisnis dan tim yang tepat. Namun, sistem ini tidak digunakan di semua tim. Mengapa Kami belajar tentang ini, serta pendekatan yang digunakan, di bawah potongan.
Artikel ini didasarkan pada laporan oleh Aleksey Troshin tentang Saint TeamLead Conf, yang menceritakan bagaimana pengetahuan disebarluaskan dalam FINAM: bagaimana Kekuatan dan keterampilan Jedi tumbuh, bagaimana Padawans dilatih dan apa yang terjadi di sisi Gelap Angkatan (di mana akan tanpanya).Produk dan Tim IT FINAM
Pertama, saya akan berbicara tentang beberapa produk kami untuk menentukan konteks perusahaan.
Situs web Finam.ru - situs No. 1 tentang topik keuangan, yang mengandung banyak bagian berbeda dengan informasi keuangan, serta layanan yang bermanfaat, misalnya, toko stok online. Anda dapat, misalnya, membeli satu saham Apple dan memberikannya kepada seseorang untuk ulang tahun.
Platform perdagangan FinamTrade , yang juga memiliki tingkat komisi nol untuk pemula.
Comon.ru - sistem pengulangan otomatis transaksi pedagang profesional - solusi untuk investor pemula dan mereka yang tidak memiliki cukup waktu luang untuk membuat portofolio investasi mereka sendiri.
Jejaring sosial untuk pedagang dan banyak lagi .
FINAM IT adalah 150 orang dibagi menjadi 25 tim. Pengembangan hanya internal, kami hampir tidak menarik perusahaan pihak ketiga untuk kebutuhan kami. Gambar judul dengan sempurna menunjukkan bagaimana semuanya diatur bersama kami. Komposisi tim dapat berbeda: beberapa tim memiliki Pemilik Produk, tetapi tidak ada penguji, misalnya, yang lain memiliki penguji, tetapi tidak ada Pemilik Produk, tetapi ada analis.
Dalam pengembangan, kami menggunakan tumpukan teknologi yang berbeda:
- Frontend: React.js, VUE.js.
- Bahasa: C #, PHP, C ++, Java, seluler.
- Basis data: MSSQL, PostgreSQL, Oracle.
- Platform: SharePoint, 1C, Diasoft, MS CRM dan banyak lagi.
Ketika saya pertama kali bergabung dengan perusahaan, kami mencoba menggambar tim, produk, dan hubungan. Hasilnya adalah skema yang sangat rumit, di mana lingkaran menunjukkan produk yang kami kembangkan:
Berdasarkan warna, saya menunjukkan bahwa tim diatur dalam berbagai cara. Beberapa membuat satu produk, yang lain membuat beberapa produk. Dan ada produk yang dikembangkan beberapa tim sekaligus (misalnya, back office internal).
Saya akan memimpin cerita saya pada contoh dua tim, saya akan memanggil mereka tim 1 dan tim 2 secara kondisional.
Tim 1
Tim pertama mengembangkan sistem informasi internal. Awalnya, ini terlihat seperti ini:
- Seorang karyawan adalah seorang ahli dalam versi platform saat ini. Ada tugas untuk mentransfer platform ini ke rel baru, karena versi lama tidak lagi didukung.
- Kami mengambil karyawan baru yang ahli dalam versi baru platform. Dia terlibat dalam porting semua fungsionalitas ke versi baru ini.
Tim 2
Tim kedua mengembangkan beberapa sistem internal:
- Satu karyawan adalah seorang ahli dalam satu sistem.
- Karyawan lain adalah seorang ahli dalam sistem lain.
- Dan beberapa sistem dikembangkan oleh kedua karyawan bersama.
Tentang para ahli
Bukan kebetulan bahwa kata "ahli" disorot dalam teks di atas. Saya ingin menjelaskan siapa ahli dalam kerangka percakapan ini. Sebagai seorang ahli dari Star Wars, orang ini memiliki Kekuatan: kompetensi yang mendalam di bidang subjeknya, dalam teknologi, dalam produk. Ini biasanya nyaman untuk bisnis, karena memberikan satu titik masuk: para ahli ditanya bagaimana melakukannya atau kapan akan dilakukan, jika itu adalah pertanyaan tentang tugas baru, atau mereka mengajukan pertanyaan jika ada sesuatu yang rusak atau tidak berfungsi dengan benar.
Saya membayangkan seorang ahli seperti Jedi Master dari film "Star Wars" - dia dapat melakukan apa saja (baik, atau hampir semuanya).
Tetapi ahli Jedi memiliki kelemahan:
- Dia perlu "dibangkitkan" untuk waktu yang lama sehingga dia menerima Kekuatan ini.
- Ketika dia pergi berlibur, selalu: "Apa yang akan kita semua lakukan?"
Untuk mengatasi pengaruh minus ini, kami telah mengembangkan sistem untuk mempertahankan matriks kompetensi, yang akan saya bahas nanti. Saya perhatikan bahwa kami tidak menerapkannya di semua tim, tetapi hanya jika ada masalah. Yang terburuk dari semuanya adalah dalam tim kecil.
Sakit kepala utama kami adalah pertanyaan, "Apa yang terjadi jika sesuatu terjadi pada ahlinya, seperti halnya Guru Yoda dalam gambar di bawah ini?"
Dan Anda mungkin juga mendengar tentang konsep faktor Bus.
Faktor bus
Faktor bus adalah ukuran konsentrasi informasi di antara anggota proyek individu.
Dalam definisi dari Wikipedia tertulis bahwa faktor ini menentukan jumlah peserta proyek, setelah kehilangan yang proyek tidak dapat diselesaikan oleh peserta yang tersisa. Secara konvensional, ini berarti berapa banyak orang yang harus memindahkan bus agar terjadi bencana yang tidak dapat diperbaiki dengan proyek.
Ketika Anda memiliki satu ahli, maka faktor Bus sama dengan satu, yaitu, semua risiko proyek berada di tangan satu orang, dan ini buruk.
Sebuah contoh dari sejarah: pada tahun 2010 di dekat Smolensk ada kecelakaan pesawat yang menewaskan 96 orang, termasuk pimpinan puncak Polandia. Setelah peristiwa ini, sebuah peraturan disetujui di Polandia - empat pemimpin utama negara (presiden, perdana menteri, pembicara Senat, pembicara Sejm) tidak boleh dalam keadaan terbang bersama. Ini adalah faktor perlindungan terhadap faktor Bus.
Seperti yang Anda ketahui, dalam tim 1 dan 2, para ahli tidak dapat dipertukarkan, dan ini menciptakan masalah potensial. Itu perlu untuk melakukan sesuatu untuk meningkatkan faktor Bus, dan untuk memperluas kompetensi para ahli Jedi. Kami telah mengambil langkah-langkah berikut.
Langkah 1. Tingkatkan faktor Bus
Jedi seharusnya tidak sendirian. Karena itu, perlu untuk melatih dan melatih Jedi, sehingga ada lebih banyak dari mereka.
Saya akan mengklarifikasi bahwa
Jedi adalah peran, bukan kompetensi . Jedi bisa dibangkitkan. Peran kedua (dalam hal Star Wars) adalah
Padawan , seorang murid Jedi. Dia berjuang untuk kepenuhan pengetahuan Jedi dan menggantikannya ketika dia sedang berlibur. Selain itu, bisa ada lebih dari satu Padawan - jika timnya besar, kami bisa mengolah beberapa Padawans sekaligus. Namun Jedi masih tetap menjadi pengambil keputusan utama.
Ketika kami memutuskan siapa yang menjadi Jedi, kami sepakat pada Padawans, mendistribusikan peran dan memvisualisasikannya di tabel manajemen:
Berikut adalah produk, area, atau modul horizontal. Misalnya, jika produknya 1C, bisa berupa “Gaji dan Personel” atau “Akuntansi” atau modul lainnya. Kolom vertikal menunjukkan karyawan. Di persimpangan kami memasuki peran - siapa Jedi, siapa Padawan. Ini menghasilkan distribusi yang jelas.
Ada beberapa aturan yang kami sepakati untuk memulai distribusi.
Aturan distribusi, bagian 1:- Satu produk, area atau modul - satu Jedi . Kami ingat bahwa kami ingin mempertahankan kenyamanan "toko serba ada", ahli dan bertanggung jawab.
- Setidaknya satu Padawan . Ini hanya tentang faktor Bus, semakin banyak, semakin baik.
- Distribusi seragam Jedi . Agar tidak membebani karyawan, secara adil.
Tampaknya semuanya didistribusikan secara logis, dan ternyata seperti ini:
Di tim pertama yang mengerjakan satu produk, satu orang mengerjakan produk lama (Sunset), yang lain pada yang baru (Sunset 2.0). Dalam versi produk "sendiri", karyawan itu dianggap sebagai Jedi, dalam versi "asing" - Padawan, seorang siswa dari karyawan lain.
Di tim kedua, karyawan yang baru tiba awalnya terdaftar di Padawans, karena mereka masih tidak tahu apa-apa tentang mereka. Dan kemudian mirip dengan Sudoku - kami mencoba untuk mendapatkan jumlah Jedi dan Padawans yang kira-kira sama dalam baris dan kolom.
Langkah 2. Kontrol berbagi pengetahuan
Tetapi bagaimana cara memverifikasi bahwa Padawan akan tumbuh menjadi Jedi, memiliki semua Kekuatan pengetahuan?
Kami memperbaiki pengetahuan
Untuk melakukan ini, kami memperbaiki pengetahuan produk kami: membuat daftar semua pengetahuan dan memasukkannya ke dalam tabel. Untuk masing-masing produk pada halaman Confluence yang terpisah, kami cukup menuliskan pengetahuan bahwa produk itu terdiri dari dan menguraikannya. Pengetahuan penguraian dapat dilakukan dengan cara yang berbeda, dan saya ingat bahwa tabel-tabel ini digambar di bawah halaman dengan distribusi Jedi dan Padawans. Misalnya, untuk tim 1, satu halaman untuk pengetahuan Sunset, halaman lain untuk pengetahuan Sunset 2.0.
Selanjutnya beberapa screenshot dari Confluence kami dengan contoh-contoh dekomposisi.
Dengan modul produk. Misalnya, salah satu produk memiliki modul perangkat lunak terpisah: pinjaman, deposito, kontrol mata uang - kami baru mengecatnya dan mulai bekerja dengannya.
Menurut fungsi. Di sini kami melukis unit pengetahuan pada halaman dan bagian dari sistem.
Untuk pengetahuan teknis. Kami menyusun beberapa produk hanya berdasarkan pengetahuan teknis tim.
Anda dapat membusuk dengan cara lain, hal utama adalah Anda bisa menyemprotkan pengetahuan tentang produk Anda ke sejumlah besar unsur atom.
Tambahkan dokumentasi
Setelah kami merinci daftar pengetahuan, kami menambahkan kolom "dokumentasi" ke tabel dan mulai mengisinya secara bertahap - setiap baris pengetahuan memiliki halamannya sendiri dengan deskripsi.
Saya harus segera mengatakan bahwa ini bukan proses yang cepat, kami butuh beberapa bulan, tetapi seiring waktu daftar dokumentasi diisi, dan pada akhirnya, di semua bidang pengetahuan tentang produk, kami telah menulis semacam dokumentasi.
Tambahkan peringkat
Lebih jauh ke kanan kolom "Dokumentasi", kami menambahkan kolom untuk setiap anggota tim dan menilai seberapa banyak setiap karyawan memiliki pengetahuan ini.
Saya akan menguraikan peringkat:
- 1 - jika Anda belum melihat atau menyentuh bidang pengetahuan ini.
- 2 - melihat atau mendengar sesuatu, tahu di mana itu. Sebagai contoh, saya membaca dokumentasi, meminta akses ke server atau ke repositori.
- 3 - dilihat, disentuh, bisa dilakukan. Sebagai contoh, saya memutuskan bug di bagian kode ini, saya memeriksa sesuatu dengan tangan saya.
- 4 - bekerja lebih dari sekali, bisa memberi tahu orang lain.
Dalam versi pertama, kami memiliki lima nilai - sekolah mengajarkan kami untuk menghitung dari 1 hingga 5. Tapi ternyata sistem empat poin sudah cukup, kami berhenti melakukannya.
Saat membuat penilaian untuk review pengetahuan, kita dapat mengajukan pertanyaan kontrol. Salah satu tim untuk memperkenalkan pendatang baru ke proyek ini memiliki video berdurasi satu jam yang perlu Anda tonton dan jawab pertanyaan pada daftar periksa. Jika seseorang tidak menjawab semua pertanyaan, diyakini bahwa dia tidak mengerti apa-apa, video perlu ditinjau, karena memiliki semua jawaban.
Langkah 3. Visualisasikan
Pada langkah ketiga, muncul pertanyaan - bagaimana saya, manajer, melihat dengan segera dan jelas bagaimana penumpukan pengetahuan dalam tim terjadi?
Kami memvisualisasikan keadaan saat ini dengan mengecat kotak Jedi dan Padawans dengan warna berbeda: hijau - pelatihan selesai, abu-abu - dalam proses pembelajaran, merah - tidak mulai belajar. Pada awalnya, biasanya banyak warna merah, tetapi pada akhirnya semua orang harus "berubah menjadi hijau."
Pada awalnya kami memainkan lampu lalu lintas dan berpikir bahwa harus ada kuning antara merah dan hijau, tetapi ternyata warna kuning cerah mengalihkan kami dari esensi. Karena itu, kami meninggalkannya dan berubah menjadi abu-abu. Sebenarnya, yang utama adalah menyingkirkan merah secepat mungkin. Gambar dengan contoh lampu lalu lintas:
Setelah itu, kami semakin menyempurnakan aturan kami.
Aturan distribusi, bagian 2:- Jedi harus "go green" terlebih dahulu. Artinya, kami fokus memompa Jedi. Kepala yang bertanggung jawab harus menjadi kompeten secepat mungkin. Apalagi jika ini adalah karyawan baru.
- Setidaknya satu Padawan harus berwarna hijau, setelah menyelesaikan pelatihan sepenuhnya. Tapi dia mungkin tidak terburu-buru untuk mengejar pengetahuan tentang Jedi, hal utama di sini adalah tidak berhenti.
- Sisanya Padawan mungkin dalam proses pembelajaran. Tugas kita adalah untuk tidak melupakan "mengotori" pengetahuan, untuk memastikan bahwa bidang pengetahuan karyawan bersinggungan dan cakupannya maksimum.
Persyaratan yang berbeda
Untuk tahap pertama memulai sistem, di mana deskripsi dan digitalisasi pengetahuan baru saja dimulai, ada praktik yang baik: untuk memisahkan persyaratan untuk Jedi dan Padawan.
Mari kita ingat kembali perkiraan: Padawan mendapat tanda hijau untuk "tiga" jika dia melakukan setidaknya sesuatu di area ini, dan Jedi harus berorientasi sempurna di area yang sama, untuk "empat". Juga, itu buruk untuk Jedi (warna merah) jika akses tidak diperoleh, dokumentasi tidak ditulis, dll, yaitu, batas bawahnya adalah "dua". Pendekatan ini diilustrasikan dalam tabel di bawah ini.
Ini sudah cukup untuk memulai. Pada tahap selanjutnya, Anda dapat menaikkan bilah dan mengatakan bahwa sekarang semua angka harus sama.
Dan sekarang piring kami dicat dan semuanya menjadi lebih menarik dan mudah dimengerti:
Kami pergi ke beberapa gambar hijau satu setengah tahun. Kami perlahan berkumpul dengan para pemimpin tim, sekali setiap dua minggu atau sebulan, menyaksikan apa yang terjadi, terus memperbarui sesuatu.
Ketika kami menambahkan fungsionalitas baru, dadu merah muncul. Kemudian pada pertemuan Timlid berikutnya, kami memeriksa apakah mereka tetap merah. Jika demikian, maka mereka mulai mencari tahu mengapa dalam dua minggu pelatihan tidak mengalami kemajuan. Jika merah hilang, kotak abu-abu tetap ada, kami secara berkala memeriksanya. Hasil dari pertemuan tim dicatat dalam Confluence pada daftar periksa, di mana status dicatat. Misalnya: “Karyawan 1 - leveling 10 dari 20”. Jika dalam dua minggu nilai-nilai ini tidak berubah, mereka mencari alasannya.
Setiap karyawan baru selalu berada di zona merah, ia harus dilatih dan dipompa sesegera mungkin. Tapi bagaimana caranya?
Langkah 4. Memompa pengetahuan dan keterampilan
Mengisi: mengisi dokumentasi
Kami memahami bahwa kami harus berusaha untuk memastikan bahwa satu baris tabel terurai produk sesuai dengan satu pengetahuan (satu halaman dokumentasi).
Deskripsi tidak sempurna hanya terlihat di tabel ini. Ini berarti bahwa bidang pengetahuan di kolom kiri terlalu detail terlalu kuat, dan di sebelah kanan mungkin ada satu lembar besar dokumentasi yang sulit dibaca dan sulit dipelajari. Yaitu, mereka membaca satu halaman dokumentasi, dan memompa 5 baris pengetahuan sekaligus - tidak masuk akal untuk mendapatkannya. Lebih baik satu baris berhubungan dengan satu halaman di Confluence. Lebih mudah untuk mencentang kotak (nomor) yang dipelajari dan dipelajari semua halaman.
Kami menggunakan dua metode pengisian:
- Menulis dari ingatan (metode ahli). Siapa pun yang tahu bagaimana melakukan sesuatu, duduk dan mulai merekam langkah-langkah mereka, misalnya, melengkapi deskripsi dengan tangkapan layar.
- Metode kedua - penelitian - yang saya lihat, kemudian saya menulis. Dengan cara ini, kami menggunakannya ketika kami bekerja dengan sistem yang tidak ada yang ingat apa yang harus dilakukan dengan itu. Karyawan itu duduk untuk memahami dan menuliskan semua yang dia lakukan dalam langkah-langkah: di sini Anda perlu meminta hak, dan kemudian menulis surat, dll. Dengan demikian, dokumentasi diisi untuk bagian yang dia selidiki.
Kebetulan minat pengembang dalam hal pengembangan diri tidak sesuai dengan apa yang dibutuhkan perusahaan. Di sini Anda bisa bermain dengan peluang. Misalnya, Anda memerlukan peningkatan keterampilan analitik, yang berarti kami memberikan koefisien 0,5 pada analitik. Menjadi jelas bahwa di sana Anda dapat "berubah hijau" lebih cepat. Tetapi di mana karyawan itu sendiri lebih tertarik, tetapi bukan tim, peluangnya lebih besar. Pada bagian ini, pemompaan akan memakan waktu lebih lama.
Selain bekerja dengan dokumen, kami melakukan pembicaraan teknologi. Tetapi dokumentasinya dasar. Saya percaya ini adalah cara terbaik untuk mengendalikan semua proses. Dalam dokumentasi, semuanya diletakkan di rak, gambar lengkap terlihat dan Anda dapat mempengaruhi penyebaran dan akumulasi pengetahuan.
Jadi, kami telah mendokumentasikan semua yang kami butuhkan. Langkah selanjutnya adalah memperbarui.
Aktualisasi
Sangat bagus ketika semua anggota tim memiliki hak untuk mengedit dokumentasi. Kemudian setiap karyawan, berkenalan dengan dokumentasi, membaca bagaimana melakukan sesuatu, dapat tersandung di suatu tempat dan segera memperbaikinya. Misalnya, nama server telah berubah atau sesuatu yang lain, seorang karyawan dapat segera mengubah dokumentasi. Dengan demikian,
pembaruan otomatis dan penambahan pengetahuan terjadi.
Jika tim Anda di ruang Confluence Anda berlangganan perubahan ini, ia akan menerima pemberitahuan di mana apa yang telah ditambahkan, diubah, ditingkatkan, karena di Atlassian Confluence ada:
- Riwayat perubahan halaman - Anda selalu dapat melihat apa dan kapan telah berubah.
- Berlangganan pemberitahuan pembaruan halaman.
- Hapus melalui tempat sampah.
Nyaman, ada penghapusan melalui keranjang. Jika seseorang secara tidak sengaja mengklik "Hapus Halaman", itu tetap tidak akan hilang. Anda dapat memulihkannya dan mencari tahu mengapa seseorang mencoba mencabut pengetahuan ini dari ruang Anda.
Sebagian besar tim kami tidak memiliki proses terpisah untuk meninjau dokumentasi. Jadi, di salah satu tim penyebaran pengetahuan sangat menyakitkan, pemimpin tim lupa melakukannya. Lalu kami mulai melakukan review di sana setiap enam bulan. Kami membuat halaman baru dan memulai dari awal lagi, tanggal tinjauan diperbaiki.
Kriteria utama untuk kualitas berbagi pengetahuan bagi saya adalah kepergian karyawan saat liburan. Jika seseorang pergi berlibur, dan tidak ada yang menulis kepada saya, tidak menelepon dan tidak meminta apa pun, maka saya pikir semuanya sudah beres dalam tim ini.
Dan jika sebelum merencanakan liburan, ada diskusi "apa yang akan kita lakukan tanpanya", bagi saya ini adalah kesempatan pada pertemuan pribadi dengan pemimpin tim untuk membahas apa yang terjadi dengan transfer pengetahuan di timnya.
Anda perlu memahami bahwa dokumentasi tidak selalu tentang membaca atau mempelajari sesuatu. Seringkali Anda perlu melakukan sesuatu: meminta akses, menginstal program, membuka sesuatu di program. Dalam tindakan ini, pembaruan terjadi. , , . , , , . .
Gunakan
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
Kesimpulan
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !