Nama saya Vladimir. Saya bertanggung jawab atas pengembangan seluler di Vivid Money.
Vivid Money adalah perusahaan rintisan fintech untuk pasar Eropa dengan berbagai fungsi - pembayaran dan transfer, multi mata uang, analisis keuangan, berbagi akun, investasi, dan banyak lagi. Pesaing terdekat adalah Revolut dan N26.
Kami berhasil membuat dan berhasil meluncurkan aplikasi fintech seluler dalam setahun. Selama tahun ini, saya mengumpulkan ide-ide yang terbentuk di kepala saya selama sekitar 4 tahun, sementara saya memimpin proyek lain. Dalam artikel ini, ide-ide ini dikumpulkan dalam bentuk tip untuk manajer / prospek rekayasa perangkat lunak yang memulai proyek jangka panjang dan skala besar dari awal.
pengantar
Lebih dari setahun yang lalu, saya datang ke proyek sebagai pimpinan tim Android. Saya dihadapkan pada tugas yang ambisius dan menarik - untuk memilih teknologi, mengumpulkan tim, mengatur proses, dan yang terpenting, melakukan semuanya dengan baik. Baik adalah konsep yang longgar, tetapi bagi saya itu adalah produk berkualitas dari sudut pandang produk dan teknis.
Memulai sebuah proyek dari awal adalah tugas yang menarik dan mengasyikkan karena tidak bisa dipahami dan sulit. Pada awalnya Anda tidak tahu apa yang harus diraih, lalu ada begitu banyak hal yang harus dilakukan sehingga seluruh proses pekerjaan seperti memadamkan api.
Untuk mencegah hal ini terjadi, pertama-tama perlu ditetapkan dengan jelas prioritas kegiatan.
Menurut saya, kegiatan utama seorang lead dapat diatur dalam urutan sebagai berikut:
- Membangun proses perekrutan;
- Memilih tumpukan teknologi;
- Menyiapkan interaksi tim;
- Membangun proses pengembangan dan pengujian.
Di bagian artikel ini, saya hanya akan fokus pada poin pertama.
Disclaimer:
Artikel ini berisi saya pikiran dan kesimpulan berdasarkan saya pengalaman bekerja di proyek-proyek besar dan jangka panjang. Beberapa tip mungkin tampak usang, tetapi seperti yang ditunjukkan oleh praktik, tidak semuanya diterapkan bahkan di perusahaan dan proyek besar.
Menyewa gedung
Bagi saya, poin ini adalah yang pertama, karena pekerjaan tim selanjutnya tergantung pada "kualitas" orang.
Kami memiliki jangka waktu yang sangat ambisius untuk meluncurkan bank - 1 tahun. Selama waktu ini, perlu untuk membuat sejumlah besar fungsionalitas secara kualitatif. Tidak ada waktu untuk bergantung, karyawan yang kurang terlatih. Oleh karena itu, saran berikut ini:
Dewan nomor 1. Ingatlah pentingnya mempekerjakan
Selain fakta bahwa pengembang yang lemah secara langsung mempengaruhi kualitas kode dan jumlah bug dalam produk, tidak mungkin untuk mendelegasikannya, karena tidak akan ada kepercayaan penuh dan pemantauan terus-menerus akan diperlukan. Oleh karena itu, kesulitan akan muncul dalam proyek yang berkembang pesat.
Dewan nomor 2. Memeriksa tidak hanya hard skill saat wawancara, tapi juga soft skill
Seringkali wawancara pengembang di Rusia bermuara pada pertanyaan bahasa / kerangka kerja. Padahal, soft skill memainkan peran yang sama pentingnya dan lebih sulit untuk dikembangkan. Selain itu, orang dengan pola pikir yang sama cenderung lebih cocok dengan tim.
Kami telah mengidentifikasi soft skill berikut untuk diri kami sendiri:
- Pemikiran sistematis;
- Kerapian dan kesempurnaan yang sehat;
- Mengandalkan pengalaman, bukan nasihat; mempertanyakan fakta yang belum diverifikasi.
Dan, tentu saja, non-konflik dasar dan kemampuan untuk berkomunikasi dengan orang-orang.
Misalnya, kami mengajukan pertanyaan kepada kandidat: “Mengapa Anda meninggalkan pekerjaan lama dan apa kriteria Anda untuk memilih pekerjaan baru?”. Jawabannya sendiri tidak begitu penting karena pendekatan sistematis itu penting - kami berharap kandidat menyadari bahwa dia tidak puas, bahwa dia dapat sampai pada ini dengan cara yang logis dan menyelesaikan semuanya di kepalanya.
Contoh pertanyaan semacam itu yang membantu kita memahami pola pikir dan prinsip seorang kandidat mungkin adalah, "Seperti apa tim ideal Anda?" atau "Seperti apa proses pengembangan yang ideal?"
Dewan nomor 3. Optimalkan wawancara Anda
Wawancara harus dilihat sebagai mekanisme yang dapat ditingkatkan dan dioptimalkan. Atau sebagai program yang dapat difaktorisasi ulang.
Saya akan memberikan contoh optimasi yang kami lakukan.
Contoh 1
Dibutuhkan sekitar 1,5 jam dua pengembang untuk mewawancarai setiap kandidat. Untuk mengoptimalkan waktu ini dan tidak menyia-nyiakannya pada kandidat yang jelas-jelas lemah, kami memperkenalkan penyaringan. Skrining adalah beberapa pertanyaan tertutup sederhana yang telah menyiapkan jawaban. Perekrut sendiri mengajukan pertanyaan ini kepada kandidat, yang memakan waktu sekitar 10-15 menit.
Beberapa angka:
Dari 100 kandidat, setelah penyaringan, sekitar sepertiga, yaitu sekitar 30, dieliminasi. Seorang perekrut menghabiskan waktu sekitar 15 menit pada setiap penyaringan, yaitu, sekitar 8 jam waktu bersih untuk 30 kandidat yang tersingkir. Dalam wawancara klasik untuk 30 kandidat yang sama, kami akan menghabiskan sekitar 60 jam kerja dalam skenario paling optimis.
Contoh 2
Tujuan wawancara adalah untuk memilih kandidat yang paling relevan. Kami menganalisis dan mengidentifikasi hard-skill dan skill penting untuk proyek tersebut, dengan mempertimbangkan tumpukan teknologi yang dipilih, yang memungkinkan kami untuk menghapus beberapa pertanyaan yang tidak relevan dan mengurangi waktu wawancara.
Misalnya, kami telah menghapus pertanyaan yang terkait dengan bagian-bagian dari Android SDK yang tidak digunakan dalam proyek kami - ContentProvider, JobScheduler, dll. Jawaban atas pertanyaan ini tidak akan memberi kami pemahaman apakah itu akan disertakan dalam pengembangan fitur proyek reguler di mana bagian-bagian ini SDK jarang digunakan.
Contoh 3
Awalnya, wawancara teknis berlangsung dalam dua tahap terpisah - pertanyaan teoritis dan tugas praktis. Ini sangat meningkatkan waktu untuk melewati semua tahap wawancara untuk kandidat, dan banyak pelamar yang kalah, karena pasar TI sangat kompetitif - pengembang yang baik mendapatkan penawaran dengan cepat.
Untuk mengoptimalkan corong, kami menutup wawancara ke tahap 1 - menghapus pertanyaan yang tidak informatif dan menyelesaikan masalah algoritmik. Saya menulis tentang pertanyaan non-informatif di paragraf sebelumnya. Tapi kami mengganti tugas algoritmik dengan tugas praktis untuk kerangka kerja. Mereka juga menguji keterampilan pengkodean dan pengetahuan SDK Anda.
Alhasil, hanya ada satu wawancara teknis selama 1,5 jam, namun isinya menjadi semulus mungkin.
Dewan nomor 4. "Pemahaman lebih penting daripada pengetahuan"
Kriteria paling penting untuk memilih pengembang adalah "pemahaman". Sehingga seseorang tidak hanya tahu bagaimana memberikan definisi dan pengetahuan akademis, tetapi menunjukkan pemahaman tentang struktur kerangka tertentu. Pengembang tanpa pemahaman ini, menghadapi masalah, tidak akan dapat menemukan solusi sendiri atau tidak akan menyelesaikan masalah dengan cukup optimal. Oleh karena itu, kami membuat semua pertanyaan wawancara terbuka sehingga kandidat tidak memberikan istilah yang dipelajari, tetapi alasan tentang satu topik atau lainnya. Dan kami mengikuti pengetahuannya tentang topik dan jalan logikanya.
Misalnya, kami mengajukan pertanyaan terbuka: "Bagaimana cara membuat detektor ANR (Aplikasi Tidak Merespons) di Android?". Pertanyaan ini menguji pengetahuan tentang cara kerja utas di Android, tetapi menghindari pertanyaan langsung tentang Looper dan Handler. Ini juga memungkinkan Anda untuk beralih secara singkat ke topik dengan multithreading.
Dewan nomor 5. Bagikan fungsi wawancara
Dengan pertumbuhan tim yang pesat, wawancara menjadi sangat banyak sehingga memakan waktu seharian, dan tidak ada waktu untuk kegiatan lain. Oleh karena itu, sangat berguna untuk mendelegasikan sebagian fungsi wawancara kepada tim.
Hal ini tidak hanya mengurangi beban dalam memimpin, tetapi juga termasuk pengembang dalam memilih rekan potensial, yang juga memotivasi dia.
Selain itu, kandidat mengenal tim dan menciptakan kesan yang lebih holistik untuk dirinya sendiri.
Dewan nomor 6. Seimbangkan pasukan
Saat merekrut, Anda harus selalu mengingat tentang keseimbangan orang berdasarkan kompetensi dalam tim. Terlalu banyak pengembang senior yang dapat mengarahkan mereka untuk menghasilkan solusi baru, tetapi pengembang tidak akan membuat fitur. Tetapi di awal proyek, ketika dasar teknis diletakkan untuk tahun-tahun mendatang, itu perlu. Selain itu, untuk menulis kode fitur yang biasa, penandatangan akan menjadi sangat mahal. Terlalu banyak junior, pada gilirannya, akan menurunkan basis kode dan, akibatnya, menenggelamkan proyek dalam jangka panjang. Namun, junior yang cerdas dengan cepat tumbuh menjadi perantara dan menjadi lebih setia kepada perusahaan dan tim daripada perantara dari pasar. Menurut saya, saldo ini berbeda untuk setiap proyek dan situasi tertentu, jadi saya tidak akan memberikan persentase tertentu.
Seringkali, tim diencerkan dengan kontraktor untuk mempercepat pengembangan. Keseimbangan juga sangat penting di sini, karena sejumlah besar kontraktor juga dapat menurunkan kode dalam proyek. Kontraktor jarang memiliki motivasi dan minat yang sama dalam suatu proyek seperti karyawan in-house.
Dewan nomor 7. Jangan takut menembak
Terakhir, tidak perlu takut memecat orang dari tim. Seseorang yang tidak cocok dengan tim dalam hal prinsip dan semangat atau dalam keterampilan teknis akan melakukan lebih banyak kerugian dalam jangka panjang daripada manfaat pengkodean jangka pendek.
Kedengarannya mudah untuk dipecat, tetapi bagaimana melakukannya semudah mungkin untuk karyawan dan tim? Prinsipnya berlaku di sini: "Tidak masalah apa yang Anda lakukan, tetapi seberapa penting itu ." Jika Anda melakukan segalanya sebelumnya - diskusikan ekspektasi dari peran tersebut, berikan umpan balik tentang pekerjaan tepat waktu, tanpa menunggu akhir masa percobaan, dan berikan alasan untuk komentar Anda - ini tidak akan mengejutkan karyawan.
Penting juga untuk memberi tahu tim kepada publik alasannyakaryawan itu dipecat. Jika tidak, Anda dapat menanamkan rasa takut dalam tim dan merusak suasana tim.
Dewan nomor 8. Kumpulkan umpan balik dari karyawan yang baru tiba
Proses rekrutmen terdiri dari 2 tahap - wawancara dan orientasi pemula.
Orientasi harus bermanfaat tidak hanya untuk pemula, tetapi juga untuk proyek tersebut.
Setelah terlibat dalam proyek, orang baru dapat melihat area masalah dan memberikan ide-ide segar dengan tampilan yang bersih. Oleh karena itu, kami telah mengembangkan aturan - untuk secara sadar mendengarkan dan menganalisis pendapat dan rekomendasi mereka untuk meningkatkan pendekatan dan basis kode. Beberapa dari rekomendasi ini telah berhasil dilaksanakan dalam proyek.
Misalnya, setelah kedatangan salah satu anggota tim Android, kami sepenuhnya merevisi pendekatan untuk menyimpan data di cache dalam memori.
Hasil
Sebagai kesimpulan, saya ingin mengatakan bahwa tim seluler kami telah berkembang menjadi 26 orang dalam waktu hampir satu setengah tahun. Semua pengembang melakukan pekerjaan dengan baik, dan tidak ada yang meninggalkan tim atas kemauan mereka sendiri. Kami telah berhasil merilis produk dan lulus uji kerja jarak jauh tanpa kehilangan kualitas dan kecepatan pengembangan.
Semoga tips yang dikumpulkan dalam artikel ini bermanfaat bagi Anda juga.
Di bagian selanjutnya, saya akan berbicara tentang pendekatan kami untuk memilih tumpukan teknologi dan menyiapkan interaksi tim.