Cara yang lebih baik untuk melatih karyawan baru [ditutup]

Tim saya saat ini bagian dari pengalaman pergantian yang cukup tinggi, dengan anggota biasanya pindah ke proyek yang berbeda dalam perusahaan yang sama. Saat ini "pelatihan" kami untuk anggota baru adalah memasangkan mereka dengan kontak utama (biasanya orang yang paling baru menyelesaikan pelatihan mereka) yang akan memberi mereka pengalaman langsung dan akan meminta lebih banyak pengembang senior jika karyawan baru meminta sesuatu dari mentor tidak tahu Ini memberikan kesempatan bagi karyawan baru untuk terlibat dengan cepat, dan menantang mentor untuk meningkatkan pemahamannya tentang sistem juga.

Namun, seperti yang dapat Anda bayangkan, gaya pelatihan ini sangat memakan waktu, dan tidak memberikan transfer pengetahuan yang sangat baik (miskonsepsi berkembang, kesenjangan meluas).

Saya telah ditugaskan untuk menghasilkan dokumentasi dan materi pelatihan untuk karyawan baru kami di masa depan. Saya sudah sering menulis teknis, tetapi ini untuk pengguna akhir dan sangat spesifik dengan banyak tangkapan layar dan menghabiskan banyak waktu untuk menyelesaikannya.

Membuat dokumentasi baru untuk karyawan baru dianggap prioritas rendah dan saat ini saya hanya punya ~ 40 jam untuk mengerjakannya. Mendokumentasikan sistem dengan cara saat ini saya menulis dokumentasi teknis hampir tidak akan menggores permukaan dalam 40 jam. Terutama mengingat saya harus mendokumentasikan tidak hanya tentang basis kode, tetapi juga tentang penyebaran dan dukungan.

Bagaimana saya bisa dengan cepat menulis dokumentasi untuk mendapatkan karyawan baru yang diperbarui secepat mungkin tanpa menginvestasikan waktu yang signifikan dalam menulis dokumentasi?

Informasi Tambahan:
Saat ini kami memiliki wiki, dan beberapa dokumentasi pelatihan, namun keduanya jarang.

Pertanyaan bagus. Programmer on-the-job training sangat jarang dianggap serius, juga tidak sering dibicarakan.

Beberapa ide yang saya lihat bekerja dengan baik:

• Di wiki Anda, miliki dokumen rampup baru-sewa (yang Anda tulis). Dalam dokumen itu, jelaskan tugas-tugas yang akan dilakukan oleh karyawan baru selama 1-2 minggu pertama. Di mana saya bekerja, ada banyak hal yang perlu diketahui dari awal, dari perangkat lunak / alat internal, ke proses, ke lokasi jenis informasi tertentu. sunting> kami memiliki instruksi seperti "instal x, y, z secara berurutan" dengan tangkapan layar untuk konfigurasi dll. Jadi, mengonfigurasi sistem atau farm (VM) dengan Win Server, SQL Server, SharePoint, BizTalk, perangkat lunak kami tidak sesederhana seperti itu. terdengar. Ini berlaku untuk versi lain dari aplikasi yang kami dukung.
• Praktekkan masalah. Di mana saya berada, kami memiliki produk yang memperlihatkan API besar-besaran. Jadi, selalu bermanfaat bagi kita untuk membaca dokumentasi produk kita sendiri untuk menulis ekstensi (ditentukan sebelumnya) seperti halnya klien / pelanggan kita. Jadi jika Anda memiliki perpustakaan matematika sebagai bagian dari API produk Anda, memiliki masalah praktik yaitu "menulis kalkulator menggunakan API kami" atau sesuatu seperti itu.
• Mentor itu baik. Simpan. Kami melakukannya di sini juga, dan bukan hanya itu cara yang baik untuk bertemu orang / berteman, tetapi mereka sangat berharga sebagai sumber pembelajaran. Saya sarankan untuk tidak menjadi orang yang paling baru menyelesaikan pelatihan karena mereka tidak memiliki sejarah pengetahuan perusahaan yang mungkin dimiliki orang lain. Mintalah setiap orang melakukannya secara bergiliran.
• Kami melakukan (kira-kira) presentasi mingguan / pembicaraan teknologi. Mintalah karyawan baru mengambil sesuatu dari produk Anda (atau menugaskannya) dan melakukan presentasi setelah minggu ke-3 mereka. Pastikan mereka tahu bahwa ada ruang bagi mereka untuk menjadi salah, dan tim dapat memperbaikinya jika mereka mengganggunya.
• Biarkan karyawan baru bekerja pada dokumentasi ketika mereka mulai. Itu memaksa mereka untuk membacanya.

Dan Dan McGrath mencatat, merupakan ide bagus untuk mendorong karyawan baru untuk meningkatkan wiki untuk mereka juga.

Pertama, saya akan menyarankan agar Anda tidak harus membuat dokumen pelatihan perekrutan baru Anda selengkap sesuatu yang Anda tulis untuk klien. Itu harus cukup teknis untuk pengembang baru untuk dapat digunakan sebagai panduan, tetapi tidak begitu rinci sehingga menguraikan setiap hal kecil. Mereka akan dapat berbicara dengan tim jika mereka memiliki pertanyaan.

Apa 10 hal teratas yang perlu diketahui oleh karyawan baru agar bermanfaat bagi tim Anda? Berkonsentrasilah pada hal-hal ini. Jadikan mereka daftar item Anda sehingga pengembang baru memiliki cukup untuk melakukan, dan informasi yang cukup untuk membuat mereka terus berjalan. Jika Anda memiliki terlalu banyak hal dalam daftar tanyakan pada diri sendiri apakah mereka akan melakukannya dalam dua atau tiga minggu pertama. Jika mereka tidak akan melakukan sesuatu saat ini, maka mungkin itu seharusnya tidak ada di panduan naik.

Untuk setiap bagian dari panduan Anda, pastikan ada orang yang disorot tepat di atas. Dengan cara ini, jika karyawan baru memiliki pertanyaan, mereka tahu ke mana harus mencari bantuan. Juga, pastikan bahwa satu anggota tim bukan orang yang tepat untuk terlalu banyak bagian. Anda tidak ingin menghabiskan waktu satu orang dengan pertanyaan-pertanyaan perekrutan baru jika mereka bukan mentor.

Jangan menghabiskan seminggu penuh untuk dokumen ini. Berikan waktu kepada diri Anda sendiri untuk menyesuaikannya setelah Anda membiarkan setidaknya satu karyawan baru melewatinya. Lihat apa yang bekerja dengan baik, apa yang tidak, dan perbaiki.

Baru-baru ini saya mulai dengan dokumen serupa di tempat kerja saya, dengan batasan waktu yang sama. Saya empati bahwa mudah untuk menulisnya pada tingkat yang sangat terperinci, seperti yang saya lakukan pada awalnya juga, tetapi itu mungkin sebenarnya kontra-produktif.

Jika seseorang baru mulai berperan, mereka kemungkinan dibanjiri informasi untuk beberapa minggu pertama. Setelah pelatihan awal mereka menjadi otak para pengembang yang telah berada di sebuah perusahaan selama beberapa tahun, akan dalam pikiran saya jauh menyulitkan apa yang perlu diketahui seseorang untuk beberapa bulan pertama atau bahkan tahun mereka di posisi itu. Pertahankan level tinggi, coba gunakan jargon dan konsep standar, lalu kembangkan dengan spesifik dari dalam proses perusahaan.

Bagi saya, pengulangan pertama dokumen ini hanyalah garis besar SDLC yang kami gunakan di tempat kerja saya, dengan daftar peran yang terkait dalam setiap langkah, beberapa contoh orang yang memenuhi peran tersebut, dan daftar periksa khusus yang terkait dengan setiap langkah siklus hidup juga. Saya pribadi menemukan daftar periksa sangat diperlukan dalam tujuan pelatihan, tetapi juga hampir semua hal lain yang saya lakukan di tempat kerja. Sebagai contoh:

• Project Manager (Joe) memberi Anda tugas di Jira.
• Tetapkan perkiraan waktu penyelesaian tugas berdasarkan rumus x.
• Tetapkan tiket sebagai 'sedang berlangsung' saat Anda mulai mengerjakannya.
• Buat cabang dari git, klik tautan untuk melihat video 30 detik tentang kemajuan ini.
• Tulis pengujian unit berdasarkan kendala dalam dokumen desain, lihat halaman y untuk konvensi penamaan pengujian unit.
• Tetapkan tiket untuk ditinjau dan kirim kode untuk meninjau sistem .. 'dll.

Karyawan baru Anda diharapkan mudah-mudahan terbiasa dengan sebagian besar konsep, dan sekarang memiliki panduan langkah demi langkah tentang bagaimana proses diterapkan di perusahaan. Saya juga melakukan demo cepat proses dari awal hingga selesai menggunakan dokumen nyata dari proyek yang saya rasa dieksekusi dengan baik.

Sebagaimana disebutkan, ini juga merupakan dokumen yang hidup, sehingga bagian dapat diperluas saat diidentifikasi bahwa mereka membutuhkan informasi lebih lanjut. Seluruh tim harus dilibatkan untuk menjaganya agar tetap terkini. Ini bisa berupa wiki, dokumen OneNote, apa pun, tetapi sesuatu yang dapat diedit dan ditinjau oleh semua orang, kemudian mulai melibatkan orang lain untuk meningkatkannya ketika mereka punya waktu luang di sana-sini. Dengan cara itu satu orang tidak melakukannya dan menyebarkan putaran mereka sendiri pada proses ke semua karyawan baru.

Setelah mereka meninjau prosesnya, minta mereka menindaklanjuti perbaikan fitur / bug kecil pada proyek kritis non misi dan minta mereka mengajukan pertanyaan yang tidak dicakup oleh dokumen tersebut. Catat apa saja pertanyaan-pertanyaan ini, karena mungkin itu adalah hal pertama yang Anda tambahkan ke dokumen pada saat Anda mengerjakannya.

Anda tidak dapat menggabungkan melakukan sesuatu yang baik ini tanpa menghabiskan waktu. Setidaknya, jika Anda ingin melakukannya sendiri. Anda harus bertanya pada diri sendiri apakah benar-benar perlu untuk mendokumentasikannya setepat yang Anda coba?

Satu-satunya alternatif adalah membiarkan karyawan baru melakukan pekerjaan utama. Biarkan mereka menulis beberapa bagian. Waktu yang Anda habiskan untuk memperbaiki ini (dalam bentuk umpan balik), akan lebih sedikit daripada dalam situasi Anda saat ini. Berikan beberapa templat yang bagus dan Anda tidak perlu khawatir tentang lay-out.

Saya percaya Anda sudah tahu bahwa mereka telah menugaskan Anda dengan misi yang mustahil. Sebagai penulis Anda mungkin sudah terbiasa dengan kutipan dari Mark Twain:

Jika saya punya lebih banyak waktu, saya akan menulis lebih sedikit.

Diberikan hampir tidak ada sumber daya, mungkin yang terbaik yang dapat Anda lakukan adalah mendapatkan lemari arsip dan meminta semua orang untuk membuat salinan dari apa yang sudah mereka miliki dan meletakkan salinan itu di lemari arsip. Dengan begitu Anda setidaknya bisa mengatakan kepada karyawan baru "Jika Anda ingin mencari sesuatu tentang sistem tempat untuk memulai ada di lemari arsip."

Menulis yang baik membutuhkan waktu, titik. Selanjutnya perlu disesuaikan dengan audiens target. Apa yang berfungsi untuk pengguna akhir tidak akan seperti yang dibutuhkan oleh seorang programmer.

Belum lagi bahwa pelatihan yang baik tidak terbatas pada materi tertulis, itu akan mencakup langkah penuh sumber daya pendidikan termasuk on-line, ruang kelas, multimedia dll.

Seperti yang mereka katakan, "Jika Anda berpikir pendidikan itu mahal, cobalah biaya ketidaktahuan."

Lebih jauh lagi tanpa mengatakan bahwa melihat dokumentasi sebagai sesuatu yang harus dilakukan setelah fakta daripada menjadikannya bagian integral dari proses sejak hari pertama merupakan indikasi masalah organisasi sistemik.