Bagaimana cara mendapatkan anggota tim baru dengan proyek ini? [Tutup]

Kami akan merekrut 1-2 insinyur baru untuk tim perangkat lunak (terdiri dari 3 pengembang, 1 tester).

Apa langkah-langkah untuk mengintegrasikannya ke dalam tim?

Ide saya adalah:

• baca dokumentasi (standar pengkodean, dokumen dalam metodologi pengembangan yang kami gunakan)
• minta mereka membaca kode yang ada
• berikan mereka beberapa tugas sederhana
• pada akhirnya, buat mereka bertanggung jawab atas bagian kode

Apa lagi yang bisa kita lakukan?

Proyek ini berada di sektor medis (sistem ultrasound), dan sudah 5 tahun berjalan. Kami memiliki rilis tahunan, dan kami akan menyelesaikan satu rilis, ketika kami ingin menambahkan 1-2 insinyur.

Proyek ini sedang dalam tahap pemeliharaan (refactoring legacy code, ditambah penambahan fitur baru). Banyak hal sesuai jadwal (kurang lebih).

Berasal dari seseorang yang harus mempercepat pada banyak basis kode yang berbeda dalam karier saya, inilah yang saya sarankan:

1. Luangkan waktu singkat (mungkin satu atau dua hari) dengan kegiatan yang terkait dengan penggunaan produk sehingga mereka dapat terbiasa dengan apa yang dilakukan produk. Ini bisa memverifikasi bug atau menjalankan rencana pengujian QA atau melalui pelatihan pengguna.
2. Kerjakan bug kecil yang dilokalkan. Ini membuat insinyur terbiasa dengan cara membangun & men-debug aplikasi tanpa harus berurusan dengan belajar banyak arsitektur.
3. Idealnya, tulis fitur kecil baru yang dilokalkan. Ini memungkinkan mereka menulis sepotong kode dan ketika mereka menulisnya mereka akan menjadi akrab dengan bit kode sekitarnya yang perlu dikerjakan oleh kode baru mereka.

Dari sana, perluas cakupan dan kompleksitas penugasan dari waktu ke waktu tergantung pada tingkat pengalaman dan kecakapan insinyur. Itu akan membiarkan pengembang memperluas pengetahuan mereka tentang basis kode secara alami.

Saya akan menghindari hanya membaca tugas (dokumentasi atau kode). Membaca dokumentasi menjadi sangat cepat sangat membosankan dan membaca kode acak tidak membantu karena mereka tidak memiliki konteks untuk dikerjakan. Cukup sulit untuk membaca kode untuk ulasan kode ketika Anda sudah tahu produk & basis kode. Saya tidak dapat melihat sesuatu yang bermanfaat keluar dari memiliki insinyur baru hanya membaca kode.

Perasaan saya adalah bahwa toleransi kebanyakan orang untuk membaca dokumentasi cukup rendah (Bagus untuk satu atau dua hari, tetapi lebih dari itu mereka mungkin gatal untuk melakukan sesuatu yang sedikit lebih langsung).

Saya tidak berpikir Anda bisa benar-benar memahami kode aplikasi tanpa pemahaman yang masuk akal dari aplikasi itu sendiri. Perangkat lunak ini mungkin memiliki banyak fungsi yang dapat mereka 'mainkan' sebagai pengguna; mereka akan perlu dapat mengujinya pada akhirnya, jadi saya berharap itu cukup penting bahwa mereka tahu cara menginstalnya, mengkonfigurasinya dan melakukan tugas-tugas umum dengannya

Saya pribadi menemukan bahwa tinjauan arsitektur tingkat tinggi biasanya cukup berguna untuk mendapatkan perasaan dasar tentang bagaimana segala sesuatu bekerja - Mungkin mengalokasikan satu atau dua jam dari waktu insinyur senior (atau diri Anda jika perlu?) Dalam minggu pertama mereka hanya untuk melalui simbol-simbol dasar dari aplikasi utama. misalnya memahami semua subsistem dan bagaimana hal-hal diikat bersama, mengetahui bit mana yang ditangani oleh perangkat lunak / perpustakaan pihak ke-3 dan bit mana yang perlu dipertahankan di rumah. (Kecuali jika organisasi Anda memiliki dokumentasi mutakhir dengan kualitas yang benar-benar luar biasa, saya kira tidak mungkin mereka akan menguasai hal-hal semacam itu tanpa seseorang menjelaskannya kepada mereka secara langsung menggunakan papan tulis: - ))

Sedangkan untuk memberi mereka sesuatu "langsung", tugas-tugas pemeliharaan / pengejaran bug mungkin merupakan cara yang baik untuk mempercepat mereka untuk sementara waktu (beberapa minggu / bulan?) - mereka akan berada dalam situasi di mana area fungsionalitas tertentu perlu dipahami, diuji, dan didebug; membantu membangun pengetahuan tentang kode, persyaratan, alat yang digunakan oleh perusahaan, proses pengembangan dan produk secara keseluruhan sementara mudah-mudahan tidak perlu menyerap terlalu banyak waktu dari anggota tim pengembang lainnya

Sebagai Pemimpin, saya menghabiskan setidaknya 2 hari dengan pengembang baru. Saya telah menemukan bahwa mengembangkan hubungan di mana rasanya nyaman untuk mengajukan pertanyaan yang tak terhindarkan "bagaimana kemajuan Anda?" Adalah sebuah keharusan. Ada ketakutan di komunitas baru mana pun yang cocok ... kita menyembunyikan kesalahan, bertindak sempurna, membuat segalanya lebih baik daripada sebelumnya, mengurangi kesulitan. Seorang manajer yang menghabiskan 2 hari bersama seseorang akan memberi tahu mereka bahwa itu bukan budaya mereka, dan memungkinkan mereka untuk memimpin dengan memberi contoh. Coders baru membutuhkan pelajaran sejarah tentang dari mana Anda berasal dan seberapa jauh Anda. Dokumen tidak melakukan tugas keadilan.

Saya hanya bekerja di industri selama 10 bulan (Saat penempatan) tetapi saya menemukan yang berikut membantu saya:

• Bekerja sama dengan pengembang lain dan mengamati bagaimana mereka mengatasi masalah.
• Menguji perangkat lunak yang membantu, saya perlu menguji fitur x yang berarti saya membaca dokumentasi pada fitur x. Saya melakukan ini banyak, itu membantu.

Keduanya membantu saya sedikit adil. Semoga berhasil.

Saya akan beralih dari level tinggi ke level rendah.

Demo aplikasi sesegera mungkin

Salah satu hal terpenting adalah bahwa pengembang memiliki gagasan tentang apa yang akan mereka kerjakan. Selama demo, tunjukkan beberapa hal yang telah dikembangkan saat ini, dan arah aplikasi yang sedang berjalan.

Jelaskan arsitektur tingkat tinggi

Ini juga sangat penting. Biarkan dev baru untuk mendengarkan dan mengajukan pertanyaan. Lakukan ini sebagai latihan bersama dengan para devs lainnya, yang diharapkan akan membantu dan membantumu. Ini akan membuat pengembang baru tahu bahwa boleh saja berbicara secara terbuka dan jujur.

Siapkan dokumen on-boarding yang bagus

Memiliki dokumen on-boarding yang bagus tidak hanya membantu pengembang baru, tetapi juga yang lama. Ini dapat berisi harapan, tautan yang berguna, dan informasi pengaturan lingkungan. (Saya tidak bisa memberi tahu Anda berapa kali saya menggunakan on-boarding kami untuk mengatur lingkungan saya ketika saya mendapatkan komputer baru ...) Ini harus terstruktur dengan baik dan to the point dan tidak berlama-lama dan tidak menjadi tempat pembuangan untuk setiap sedikit detail.

Dorong dia untuk mengajukan pertanyaan (dan siap menjawabnya)

Dengan jawabannya, bimbing mereka, tetapi jangan memberi tahu mereka apa yang harus dilakukan. Beri mereka petunjuk tetapi biarkan mereka akhirnya mengetahuinya sendiri.

Bantu anggota tim lainnya menyambut pendatang baru

Ada dua sisi mata uang ketika seseorang bergabung dengan tim. Tim perlu memiliki alat untuk menyambut pengembang baru juga.

Biarkan mereka mengambil satu atau dua tugas kecil

Izinkan mereka untuk menambahkan sesuatu yang baru dan terlihat ke proyek yang mampu demo. Saat demo, panggil siapa yang melakukannya dan betapa bagusnya pekerjaan yang mereka lakukan. Ini benar-benar dapat meningkatkan harga diri. Semakin cepat mereka merasa seperti menambah nilai, semakin cepat mereka merasa menjadi bagian dari tim. Semakin cepat mereka akan merasa diberdayakan untuk melakukan yang terbaik yang mereka bisa.

Dorong mereka untuk melakukan tugas yang lebih sulit begitu mereka merasa lebih dan lebih nyaman

Kandidat yang baik akan melakukan ini secara alami.

Satu aliran "orientasi" yang telah saya lalui (dan bermanfaat) adalah sesuatu di sepanjang baris:

1. Presentasi singkat memberikan "Gambaran Besar" tentang komponen-komponennya, bagaimana kesesuaiannya dan arsitektur umumnya.
2. Tinjauan umum kode, pengantar fungsi yang menangani logika utama untuk komponen yang ditugaskan kepada saya. Mencakup beberapa hal yang berkaitan dengan konvensi dan gaya pengkodean.
3. Banyak masalah terbuka dan bug prioritas rendah ditugaskan (yang sebagian besar dilokalisasi ke komponen yang ditugaskan kepada saya dan cukup sederhana).
4. Saya diharapkan untuk debug melalui aplikasi dan meminta bantuan dengan hal-hal yang saya tidak bisa menguraikan.
5. Setelah perbaikan dilakukan, saya berjalan melalui proses (review kode, pengujian tingkat dev dll) untuk melepaskan integrasi.
6. Ulangi untuk tugas / bug yang tersisa yang dialokasikan.

Saya merasa pendekatan ini (dan variasi darinya) akan bermanfaat karena:

• Ini lebih praktis dan relatif independen (konstan tanpa pegangan dll.). Jadi, ini menyediakan ruang / waktu yang cukup bagi orang baru untuk membiasakan diri dengan kode dan cara melakukan sesuatu dalam tim.
• Hal ini juga bermanfaat bagi tim secara keseluruhan karena beberapa tugas / bug dengan prioritas rendah dapat diselesaikan. Orang yang membantu orang-orang baru juga memiliki lebih banyak waktu untuk menangani tugas-tugas yang diberikan kepada mereka karena tidak perlu berpegangan tangan dan waktu dapat secara khusus dijadwalkan untuk menangani masalah / masalah yang mungkin dihadapi orang baru.

Perekrutan awal perlu membutuhkan tugas yang kecil, tetapi tidak terlalu kecil, dan terdefinisi dengan baik untuk dikerjakan. Dengan cara ini mereka dapat mulai merasakan bagaimana kode disusun dengan mencoba mencari cara untuk menyelesaikan tugas mereka. Dalam proses, pertanyaan akan muncul dan pada saat itu Anda dapat mengarahkan mereka ke dokumentasi atau sumber daya lain yang dapat mereka gunakan untuk membantu mereka menginternalisasi basis kode. Ini juga membantu jika siklus pengembangan, komit, penyebaran Anda pendek dan mereka dapat melihat hasil kerja mereka secepat mungkin.

Inilah yang saya lakukan

1. Beri mereka beberapa tugas yang terkait dengan proyek (misalnya: Jika proyek Anda adalah aplikasi basis data, minta mereka hanya membuat aplikasi untuk terhubung dengan database dan melakukan beberapa operasi sederhana.)
2. Ketika Anda menemukan mereka telah memahami ide untuk bekerja, beri mereka demo Proyek
3. Minta mereka membaca dokumentasi.
4. Buat mereka terbiasa dengan gaya dan standar pengkodean
5. Kemudian beri mereka beberapa latihan debugging (untuk mengetahui aliran proyek).
6. Minta mereka untuk memperbaiki titik yang sudah Anda perbaiki (hanya untuk mengetahui logikanya dengan itu).
7. Akhirnya jadikan mereka bagian dari proyek.

Ingat: tidak peduli berapa banyak Anda mencoba, sampai dan kecuali jika joinee memahami proyek sepenuhnya, Anda tidak akan dapat menyelesaikan pekerjaan dengan efisien darinya.

Nomor satu - pertama-tama pelajari cara menggunakan perangkat lunak untuk menemukan masalah apa yang dipecahkannya dari perspektif pengguna. Jika tidak memiliki UI (misalnya layanan backend atau sesuatu), biarkan mereka menggunakan antarmuka apa pun yang tersedia untuk menggunakannya. Mendapatkan pandangan baru tentang pandangan pengguna terhadap perangkat lunak Anda selalu baik, dan itu mungkin membantu karyawan baru untuk melihat hal-hal yang tidak dapat Anda lakukan, karena Anda sudah tertanam dalam proyek tersebut.

Setelah ini, proyek pertama yang bagus mungkin sesuatu seperti modul tambahan atau baru untuk ditambahkan ke perangkat lunak, meminimalkan jumlah pengetahuan yang dibutuhkan dari basis kode yang ada. Menulis sesuatu yang baru akan selalu lebih mudah daripada melakukan perbaikan bug, yang mungkin membutuhkan banyak perubahan di banyak file sumber. Menurut pendapat saya, memberi karyawan baru tugas perbaikan bug mungkin akan mematikannya dari perusahaan Anda.

Garis besar Anda untuk membiasakan yang baru dengan proyek tampaknya masuk akal. Tetapi perlu diingat bahwa mereka akan memiliki banyak belajar di awal. Ini biasanya situasi yang luar biasa. Anda harus bersabar dan menjawab pertanyaan yang sama berulang kali. Ini normal, pengembang baru harus belajar banyak, jangan meremehkan ini. Jika Anda marah dengan pertanyaan berulang ini, Anda akan mengambil risiko bahwa mereka tidak akan bertanya dan mencoba mencari tahu sendiri hal-hal yang mungkin paling lambat tetapi sering kali tidak mungkin. Mereka juga harus belajar bahasa. Sebagian besar proyek tim mengembangkan bahasa mereka sendiri. Ketika menjelaskan secara sadar cobalah untuk menghindari istilah. Jelaskan hal ini seperti Anda akan menjelaskannya kepada ibumu. Sekali lagi, bersabarlah.

Selain itu, Anda dapat mencoba mengintegrasikannya dengan yang lain yang sudah ada dalam tim dengan mencoba beberapa tugas gaya pusat penilaian misalnya membangun jembatan dalam 45 menit dari 4 lembar kertas yang mendukung cangkir kopi. Kami menggunakan teknik ini dalam kursus praktis dalam rekayasa perangkat lunak untuk membuat sekelompok 8 siswa memecahkan kebekuan sebelum mereka mengerjakan satu proyek selama 3 minggu. Ini membantu mempercepat fase pembentukan tim.

1) Beri mereka penjelasan tentang aturan dan pedoman kode Anda. Juga berikan penjelasan umum tentang cara kerja aplikasi Anda dan struktur kode umum.

2) Temukan beberapa bug kecil atau proyek yang sebagian besar tidak tergantung pada kode lain. Jelaskan apa yang perlu dilakukan, di mana dalam kode dan periksa secara teratur.

3) Perlahan-lahan mulai memberi mereka proyek yang lebih besar dan lebih besar sambil memeriksa mereka semakin sedikit.

4) Duduk di sebelah mereka dari waktu ke waktu. Anda dapat belajar banyak hanya dengan melihat bagaimana orang lain mengatasi masalah. Hal-hal kecil seperti "oh, Anda dapat mencari fungsi dalam kode Anda dengan mempresentasikan ctrl-." sangat bermanfaat.

Sekarang, saya telah menemukan bahwa ada dua ekstrem :

• Seseorang yang mengajukan pertanyaan setiap lima menit. "Apa yang dilakukan Path ini. Bergabung?" Mereka harus Google terlebih dahulu untuk jawaban dan hanya datang kepada Anda ketika mereka tidak dapat menemukan jawaban.

• Dan yang ekstrem lainnya, seseorang yang bekerja setengah hari tanpa mengajukan satu pertanyaan pun. Mereka seharusnya merasa itu hal yang baik untuk bertanya. Saya hanya ingin mereka mencobanya terlebih dahulu.

Ini adalah formula saya dan digunakan dengan beberapa pendatang baru - langkah-langkah ini terbukti sangat efektif.

a) Semua pengembang baru akan diberikan pengantar tentang persyaratan proyek dan proses pengembangan selama 2 hari.

b) Menugaskan 3 minggu tugas menulis tes Junit untuk kode yang tidak memiliki cakupan yang cukup.

c) Setelah 3 selesai, tetapkan tugas-tugas kecil

d) Menetapkan tugas yang rumit dan selesai.

Saya pikir hanya menetapkan beberapa tugas kecil, minta mereka untuk menulis beberapa tes unit, membuat mereka men-debug beberapa regresi gagal. Tidak ada yang terlalu besar atau menuntut, tetapi cukup untuk membuat mereka berdiri.

Anda juga harus menugaskan pengembang senior, lebih disukai per pengembang baru yang dapat membantu mentor kandidat.

Dan ya, buat mereka mendokumentasikan apa yang mereka pelajari tentang sistem. Saya berasumsi di sini bahwa Anda memiliki semacam halaman wiki internal. Jika tidak, itu pasti suatu keharusan baik dalam jangka panjang maupun jangka pendek - cara yang sangat cepat untuk membuat orang-orang meningkat. Halaman wiki tidak boleh hanya berisi dokumentasi kode, tetapi juga hal-hal seperti batasan yang diketahui (ini adalah perangkat lunak: D), solusi, metrik kinerja waktu / memori dll.

Jangan hanya menjelaskan praktik dan standar pengkodean yang baik, tetapi jelaskan bagaimana kode baca terstruktur. Jelaskan apa yang seharusnya dilakukan oleh perangkat lunak dan bagaimana ini atau akan dicapai.

Mereka tidak akan mengerti sampai ada beberapa pekerjaan yang harus dilakukan, jadi saya sarankan untuk membagi menjadi dua bagian, satu sebelum mereka memulai pekerjaan nyata, dan bagian dua, setelah mereka mulai bekerja. Mereka akan melihat beberapa kode atau dokumentasi dan berpikir " WTF !? " Ketika ini terjadi, seseorang akan menemani mereka dan menjelaskan detail kecil.