Onboarding di situs jarak jauh

Ada beberapa jenis orientasi: di tingkat perusahaan, ketika semua orang menunjukkan dan memberi tahu seorang pemula tentang aktivitas, fitur, strukturnya; di tingkat SDM, yang masih bisa menekankan kesan kerja; dan di tingkat tim. Kami akan berbicara tentang yang terakhir, terutama tentang bagaimana persyaratan untuk perubahan onboarding selama pekerjaan jarak jauh.

Bekerja sebelum udalenka dan sesudahnya.
Bekerja sebelum udalenka dan sesudahnya.

Apa saja opsi untuk orientasi?

  • Mereka melemparkannya ke dalam air, berenang - manusia kita tidak bisa - itu adalah kesalahannya sendiri, lebih baik untuk mencoba dan belajar berenang terlebih dahulu;
  • Inilah tugasnya, di sini Anda akan memahami sisa kampanye;
  • Orientasi nyata. Dalam kasus pertama, sebenarnya tidak. Pendatang baru terlibat dan tenggelam dalam perusahaan dan tim perangkat.

Saya akan melakukan reservasi, dalam artikel ini saya tidak fokus pada pemisahan orientasi senior atau junior. Proses-proses ini memiliki fokus pada detail teknis dan kontrol pekerjaan, tetapi sama pentingnya.

Aspek sosial


Pengembang adalah makhluk sosial dan kemungkinan besar adalah seorang introvert. Pengembang berpengalaman mungkin memiliki keterampilan komunikasi yang baik atau bahkan menjadi ekstrovert. Tapi tetap saja lebih baik mendorongnya sedikit untuk berkomunikasi.

Bertemu dengan tim


Perkenalkan kolega baru ke tim, luangkan lebih banyak waktu di bagian informal, bicarakan hobi atau fakta menarik lainnya tentang seorang pemula . Jika seseorang tertutup dan tidak siap untuk membagikan minatnya, sentuh sorotan dari pekerjaan sebelumnya. Kemungkinan besar, dia sudah memberi tahu Anda sebagai pemimpin tentang mereka pada saat wawancara. Ini penting, dalam kehidupan sehari-hari di kantor, seorang pemula bisa menceritakan hal ini kepada rekan-rekannya saat istirahat atau saat makan siang, sementara bekerja dari jarak jauh lebih sulit dilakukan.

Tidak peduli seberapa besar perusahaan Anda, tunjukkan proyek yang akan dikerjakan oleh seorang pemula. Fokus pada siapa yang melakukan tugas apa sekarang. Jika proyeknya besar, dan Anda menyarankan pemula untuk mencari dan mengajukan pertanyaan sendiri, ia mungkin pergi untuk mempelajari bagian yang tidak relevan atau hanya menggali. Belum lagi fakta bahwa jika Anda memiliki layanan Microsoft, beberapa aplikasi seluler, dan situs web, seorang pemula tidak akan dapat memprioritaskan dengan baik.

Kami ingin menggunakan waktu secara optimal dan kami membuat instruksi panjang yang menjawab banyak pertanyaan. Jadi mungkin Anda bisa mengirim pemula “Baca Manual Mewah”? Sekarang setiap orang memiliki kekurangan kontak sosial, lebih baik menghabiskan sedikit lebih banyak waktu untuk komunikasi langsung .

Atur pertemuan dengan bisnis. Ketika Anda duduk di kantor dan produk berjalan dalam kepanikan, kata mereka, galeri foto tidak berfungsi, pemula akan segera memahami bahwa ini adalah bagian penting / kunci dari proyek. Tanpa melihat hutan terbakar di dekat Anda, Anda bisa lupa bahwa itu terbakar. Biarkan bisnis menunjuk, dan kemudian mengingat, apa yang sebenarnya penting untuk pengembangan proyek.

Di lokasi terpencil, karyawan bekerja lebih produktif, karena tidak ada yang mengalihkan perhatian mereka. Kerja jarak jauh yang dipaksakan saat kita mengeluarkan kurung. Tetapi proses ini stabil dan baik, selama pengembang memiliki semua data yang diperlukan. Jika tidak ada data, Anda harus mendapatkannya di suatu tempat. Dan di sini seorang pemula dapat kehilangan banyak waktu mencari mereka, karena dia tidak segera mencari tahu siapa mereka dapat diminta. Dan pertukaran pengetahuan, siapa yang bertanya dan ke mana harus mencari, adalah ruang lingkup yang signifikan untuk mengoptimalkan pekerjaan seorang pemula .

Secara bertahap, seorang karyawan baru akan bertemu semua kolega. Dan "secara bertahap" adalah kata kunci di sini. Akan lebih baik memiliki daftar dalam pertemuan yang menunjukkan siapa dan dalam hal mana Anda dapat menghubungi. Tetapi Anda tidak boleh membuang daftar 20 nama ke karyawan baru dengan penjelasan singkat tentang siapa dan mengapa dia perlu, dan berharap ini sudah cukup.

gambar


Saya merekomendasikan pendekatan buddy , dijelaskan dengan baik dalam laporan Lamoda . Buddy adalah anggota tim yang berdedikasi yang akan menjawab semua pertanyaan tentang perendaman di perusahaan. Mitra akan memberi tahu Anda siapa yang harus dihubungi untuk masalah tertentu - bukan di departemen mana, tetapi kepada siapa secara spesifik. Akan memberi tahu jika ada fungsi atau microservice serupa. Ini akan membantu untuk berurusan dengan gaya komunikasi dan perilaku yang diadopsi perusahaan.
Ketika bekerja dengan produk, sekelompok pop-up dan momen yang tidak terduga untuk seorang pemula muncul, ia dapat segera mengajukan pertanyaan dan memahami apa itu dan mengapa itu dilakukan. Bahkan jika mentor tidak tahu, pengalamannya di perusahaan harus cukup untuk mengetahui siapa yang harus ditanyakan.

Di tempat terpencil Anda tidak bisa lewat dan bertanya apa kabar. Inilah saat yang harus diambil seorang rekannya. Komunikasi yang konstan dengan dia mengkompensasi masalah ini. Jika orang ini tidak ada, perannya biasanya diberikan kepada pemimpin, yang tidak kurang sibuk dalam pekerjaan jarak jauh dan dia tidak punya waktu untuk bereaksi dengan segera. Memilih "teman" seperti itu, Anda perlu memperhitungkan keterampilan komunikasi dan keinginan orang itu sendiri - seseorang ingin kode dengan tenang, dan Anda tidak boleh menyalahkannya.

Menjauh dari pertanyaan umum dan khusus . Untuk pertanyaan standar “apakah ada masalah?” Anda kemungkinan besar tidak akan mendapatkan jawaban yang jelas. Perlu ditanyakan apakah seseorang menghadapi tugas tertentu, apakah semuanya jelas baginya di sana. Dalam hal ini, kemungkinan umpan balik kualitas lebih tinggi, ia dapat mengingat (dan tidak ragu untuk mengatakan) bahwa ia memiliki pertanyaan tentang topik ini.

Aspek teknis


Memiliki pengarahan teknis tentang proyek tersebut. Bagi menjadi beberapa pertemuan. Selama yang pertama, beri tahu poin-poin umum. Yang kedua - tentang interaksi dengan departemen lain. Pada pertemuan ketiga, perkenalkan infrastruktur. Periksa kembali dokumentasi , perbarui setelah karyawan, ketika ada cacat. Kapan, bukan jika! Ambil tugas yang tidak memerlukan persetujuan jarak jauh sebelumnya. Idealnya, cobalah membuat sketsa tugas ini sendiri dan memeriksa relevansi deskripsi.

Berbicara tentang suatu proyek, Anda memperkenalkan banyak istilah yang tidak berarti apa-apa bagi seorang pemula. Misalnya, "Katney Gosu di Republik Kazakhstan". Saat memperkenalkan istilah baru, berikan penjelasan kepada pemuladan dosis informasi tersebut. Jika Anda memberi tahu seluruh infrastruktur layanan dalam satu pertemuan, pemula kemungkinan besar akan melupakan hampir semua konsep yang belum ia temui dalam beberapa hari ke depan.

Cobalah untuk memberikan tugas berpasangan pertama kali . Bahkan jika satu orang dapat melakukan tugas, lebih baik membaginya menjadi sub-tugas sehingga ada kerja sama. Ambil microservice, misalnya. Katakanlah seorang pemula membuat lapisan komunikasi dengan DB, dan rekan yang lebih berpengalaman memiliki kerangka kerja dan komunikasi yang sama dengan API. Selanjutnya, pemula akan menulis logika bisnis, dan tugas akan masuk ke pengujian sebagai microservice lengkap.

Tugas-tugas semacam itu membantu membangun dengan cepat ke dalam ritme tim seorang kolega yang duduk di ujung Skype (Zoom, Hangout) jika ada masalah yang muncul dan memungkinkan pendatang baru merasa bahwa dia tidak sendirian. Ini juga melindungi karyawan baru dari perubahan yang tidak perlu dari setengah basis kode, jika dia tiba-tiba: 1) salah memahami tugas, 2) ingin menunjukkan ambisinya dan membunuh 48 jam tanpa tidur.

Udalenka menyiratkan peningkatan rasa ketidakpastian. Sebuah rencana membantu mengatasinya secara kualitatif. Bukan semboyan, semuanya berjalan sesuai rencana, tetapi rencana yang dirumuskan untuk melibatkan seorang karyawan dalam detail proyek. Dan juga rencana pengembangan karyawan. Dan tentu saja, jelas menggambarkan tujuan karyawan pada masa percobaan dan harapan dari seorang pemula. Mereka tidak harus terikat pada tugas sprint, tetapi ke poin-poin umum yang penting bagi perusahaan pada setiap tahap pengembangan. Contohnya:

  • Dapatkan akses dari (nama penanggung jawab);
  • Perluas cabang tugas pada lingkungan pengujian;
  • Melakukan 5 tugas review rekan kerja;
  • Lihat persyaratan tata letak dev-ops;
  • Ambil pertemuan umpan balik pertama.

Contoh terakhir penting, di sini rapat ditetapkan untuk menerima umpan balik, yang sudah saya katakan banyak di bagian sosial. Daftar Anda akan berbeda tergantung pada prioritas tim dan kualifikasi karyawan. Anda dapat secara langsung menyorot bagian umum dan yang tambahan untuk junior, menengah dan depan / belakang.

Memiliki daftar tugas yang harus dilakukan dan persyaratan untuk masa percobaan akan menyelamatkan Anda dan kolega baru Anda. Ini akan memungkinkan karyawan untuk menunjukkan dirinya dari sisi yang berbeda dalam waktu yang cukup singkat, sama dengan tes, dan terjun ke berbagai bidang pekerjaan Anda. Jika Anda tidak melakukan ini dan memberikan seorang pemula, misalnya, dengan tenang menggergaji satu modul, dalam 3 bulan ia idealnya akan melakukannya, tetapi mungkin ternyata tidak efektif di banyak momen lainnya.

Bagaimana memahami bahwa orientasi berhasil di situs jarak jauh?


Seseorang seharusnya tidak memiliki kesan tim sebagai satu set piksel di layar. Harus ada pemahaman tentang apa yang terjadi di sekitar tim. Memahami proyek harus dikaitkan dengan fitur-fitur khusus yang dibuat oleh orang-orang yang hidup dengan siapa dia berhasil bekerja dan berkomunikasi.

Kami telah melakukan pertemuan dengan umpan balik dari anggota tim lain, di mana mereka berbagi pengalaman dengan pemimpin tentang interaksi dengan pendatang baru dan kesan umum. Untuk produktivitas rapat semacam itu, lebih dari setengah karyawan harus sudah memiliki pengalaman berkomunikasi dengan kolega baru. Jika mereka mengklaim bahwa "pekerjaan itu berhasil, itu tidak mengganggu saya", maka proses orientasi harus diselesaikan.

All Articles