Meningkatkan tim pengembangan Anda dengan insinyur eksternal tanpa kehilangan kualitas kode

Pengantar

Poin penting

1. Gunakan insinyur eksternal ketika roadmap Anda terlalu padat untuk tim inti Anda.
2. Tetapkan batasan kualitas sederhana dan alur pengiriman dasar sebelum mereka bergabung.
3. Onboarding insinyur eksternal dengan daftar periksa yang jelas dan satu rekan yang dapat diandalkan.
4. Terapkan satu set aturan, tinjauan, dan metrik yang sama untuk semua insinyur.
5. Andalkan pembaruan tertulis singkat untuk menjaga tim gabungan yang berkembang tetap sejalan.

Mengapa Anda perlu memperluas tim pengembangan Anda dengan insinyur eksternal?

Anda harus memperluas tim pengembangan dengan insinyur eksternal ketika roadmap Anda penuh dan tim internal Anda tidak dapat mengikuti dengan cara yang sehat. Poin utamanya sederhana: insinyur eksternal harus menambah kecepatan dan keterampilan tanpa menurunkan standar kualitas Anda. Jika mereka membantu Anda menghasilkan pekerjaan yang stabil dan aman untuk dipelihara, pengaturan ini masuk akal. Jika mereka hanya menambah stres dan perubahan acak, timing-nya tidak tepat.

Banyak pemimpin di perusahaan produk merasakan tekanan yang sama. Tumpukan pekerjaan menumpuk, tenggat waktu terlewat, dan merekrut insinyur yang kuat di kota Anda memakan waktu lama. Pada saat itu, Anda mulai mempertimbangkan untuk memperluas tim engineering dengan bantuan dari luar. Anda mungkin melihat tim pengembangan outsourced di wilayah lain atau kelompok kecil yang lebih dekat dengan zona waktu Anda. Pertanyaan sebenarnya bukan apakah Anda bisa membawa bantuan eksternal, tetapi kapan hal itu akan mendukung roadmap Anda daripada menyembunyikan masalah yang lebih dalam.

Salah satu alasan mengundang insinyur eksternal adalah akses ke keterampilan yang saat ini tidak Anda miliki di dalam perusahaan. Anda mungkin membutuhkan dukungan jangka pendek di bidang seperti data, aplikasi seluler, atau pengaturan cloud baru. Anda mungkin tidak ingin membangun tim baru sepenuhnya untuk setiap topik baru. Dalam hal ini, penambahan tim pengembangan perangkat lunak dapat memberikan lapisan dukungan fleksibel di sekitar tim inti Anda. Anda mempertahankan pengetahuan inti dan arah di dalam perusahaan Anda dan menggunakan bantuan eksternal untuk bagian pekerjaan yang jelas dan terfokus. Dalam kehidupan sehari-hari, ini terasa lebih seperti menambahkan satu ahli yang tenang ke dalam tim yang sibuk daripada menciptakan perusahaan kedua.

Ada juga aspek waktu dan biaya yang sangat dasar. Merekrut orang-orang yang kuat secara mandiri dapat memakan waktu berminggu-minggu atau bahkan berbulan-bulan, dan selama itu, tumpukan pekerjaan Anda tidak berhenti. Di sini Anda dapat melihat manfaat penambahan staf IT yang jelas. Anda dapat membawa tenaga tambahan untuk waktu dan ruang lingkup yang ditentukan sambil tetap mempertimbangkan perekrutan jangka panjang. Bagi beberapa tim, opsi ini meratakan puncak permintaan daripada memaksa lonjakan besar dalam jumlah karyawan tetap. Pengaturan semacam ini memungkinkan Anda menguji apa yang dilakukan kapasitas tambahan untuk produk Anda sebelum mengubah struktur keseluruhan secara permanen.

Anda juga dapat memilih model berbeda untuk cara orang-orang ini bergabung dengan tim Anda. Dalam model penambahan tenaga kerja, Anda menambahkan insinyur eksternal ke tim Anda sendiri dan pemimpin Anda mengarahkan pekerjaan mereka setiap hari. Dalam pengaturan tim pengembangan nearshore, orang-orang berada di zona waktu yang dekat dan dapat bergabung dalam panggilan dan obrolan Anda pada jam kerja normal. Banyak perusahaan bekerja sama dengan mitra pengembangan perangkat lunak berpengalaman yang sudah tahu cara melakukan pengembangan perangkat lunak nearshore dan berintegrasi dengan tim internal. Semakin dekat budaya, zona waktu, dan alat yang digunakan, semakin mudah membuat banyak orang merasa seperti satu tim, meskipun kontrak berbeda. Dasar bersama ini yang membuat kerja eksternal terasa alami daripada rapuh.

Bagaimana Anda mempersiapkan basis kode dan proses sebelum menambahkan tim pengembangan eksternal?

Anda mempersiapkan tim pengembangan eksternal dengan menetapkan dasar yang jelas dan sederhana tentang cara Anda membangun dan meluncurkan produk Anda. Anda memerlukan aturan bersama, alat dasar, dan cara kerja yang terlihat sebelum orang baru datang. Tanpa dasar ini, setiap perubahan bergantung pada gaya pribadi dan ingatan, dan orang baru tidak memiliki cara untuk menebak jalur yang benar. Dengan dasar ini, bahkan mata baru pun dapat bergerak dengan ritme yang aman dan stabil.

Anda dapat memikirkan dasar ini sebagai pagar pengaman kualitas untuk kode. Pagar pengaman ini adalah pemeriksaan sederhana yang harus dilalui setiap perubahan, terlepas dari siapa yang menuliskannya. Mereka dapat mencakup cara Anda menamai hal-hal, cara Anda memformat file, dan apa arti "selesai" untuk setiap bagian kecil pekerjaan. Ketika pagar pengaman tetap sama untuk semua orang, produk Anda terasa stabil meskipun tim tumbuh dan berubah. Ini memudahkan untuk mempercayai alur kerja secara keseluruhan, bukan hanya orang-orang yang sudah Anda kenal.

Anda juga memerlukan pipeline integrasi dan pengiriman berkelanjutan dasar. Frasa panjang ini menggambarkan ide sederhana. Setiap kali seseorang mengubah kode, sistem menjalankan pemeriksaan dan membantu memindahkan perubahan tersebut ke pengguna dalam langkah-langkah kecil dan aman. Pipeline ini dapat berjalan di platform umum dan dapat dijalankan setiap kali ada push ke repositori kode utama Anda. Pipeline yang berfungsi mengubah banyak perubahan kecil menjadi garis kemajuan yang rapi, bukan tumpukan rilis besar yang menakutkan. Orang baru dapat mempelajari jalur ini sekali dan kemudian mengikutinya tanpa tebak-tebakan tambahan.

Uji coba adalah bagian kunci dari jalur ini. Pengujian otomatis dalam CI/CD berarti pengujian Anda berjalan secara otomatis setiap kali seseorang membagikan kode baru. Anda dapat memulai dengan pemeriksaan sederhana yang mencakup jalur paling sering digunakan dalam produk Anda. Seiring waktu, Anda dapat menambahkan lebih banyak pengujian saat melihat di mana bug cenderung muncul. Bahkan sekumpulan pengujian yang stabil dan kecil memberikan keamanan lebih daripada daftar panjang pengujian manual yang tidak pernah dijalankan tepat waktu. Pendekatan ini menjaga hal-hal tetap realistis dan mendukung insinyur internal maupun eksternal.

Ini juga membantu untuk memeriksa bagian-bagian lama sistem Anda sebelum meminta orang lain untuk mengutak-atiknya. Di sinilah manajemen utang teknis dasar berperan. Utang teknis adalah cara untuk menggambarkan kode yang berfungsi tetapi sulit diubah tanpa risiko. Anda dapat menandai zona yang aman untuk orang baru dan zona yang masih memerlukan perawatan dari staf berpengalaman Anda. Ketika Anda tahu di mana bagian berisiko berada, Anda dapat mengarahkan tim pengembangan eksternal ke area yang lebih aman terlebih dahulu. Ini melindungi produk Anda dan menjaga orang baru agar tidak terjebak dalam jebakan tersembunyi.

Bagian terakhir dari dasar ini adalah keamanan dan akses yang sederhana. Siklus pengembangan perangkat lunak yang aman terdengar rumit, tetapi didasarkan pada langkah-langkah yang jelas. Anda memberikan akses hanya sesuai kebutuhan, menjaga data pengguna asli tetap aman, dan menangani kunci rahasia dengan hati-hati. Anda juga mencatat apa yang harus dilakukan jika terjadi masalah, bahkan pada skala kecil. Ketika keamanan menjadi bagian dari pekerjaan rutin, insinyur eksternal dapat bergabung dalam proses Anda tanpa menimbulkan ketakutan baru. Tim hukum dan keamanan Anda juga melihat bahwa pertumbuhan ini mengikuti rencana, bukan solusi cepat.

Bagaimana rencana onboarding yang aman untuk pengembang eksternal?

Rencana onboarding yang aman untuk pengembang eksternal memberikan konteks, alat, dan langkah awal yang jelas tanpa terburu-buru memasukkan mereka ke dalam situasi yang rumit. Ini harus terasa seperti jalur yang terarah di mana setiap hari memiliki tujuan yang sederhana dan nyata. Ketika rencana jelas, orang baru dapat memberikan nilai tambah dalam hitungan minggu, bukan bulan, dan tim Anda sendiri tidak merasa kelelahan oleh pertanyaan yang terus-menerus.

Onboarding pengembang eksternal dimulai dengan pemahaman bersama tentang apa yang perlu mereka pelajari terlebih dahulu. Ini mencakup produk Anda, pengguna Anda, dan cara kerja normal Anda. Daftar periksa onboarding untuk pengembang dapat menampung semua item ini dalam satu tempat. Daftar ini dapat disimpan dalam dokumen sederhana yang dapat dibuka dan disesuaikan oleh kedua belah pihak. Daftar periksa yang terlihat mengubah "Saya pikir kami sudah memberitahu mereka ini" menjadi "kami tahu persis apa yang sudah dilakukan dan apa yang selanjutnya." Perubahan kecil ini menghilangkan banyak stres yang tidak terucapkan bagi semua orang.

Berikut adalah daftar sederhana yang sering kali menjadi dasar yang baik untuk daftar periksa semacam ini:

1. Akses ke kode, pelacak pekerjaan, dan ruang obrolan utama.
2. Langkah-langkah untuk menjalankan produk di laptop atau server uji.
3. Panduan singkat tentang pengguna, alur utama, dan aturan bisnis kunci.
4. Nama-nama orang yang dapat dihubungi mengenai produk, kode, dan alat.
5. Dua atau tiga tugas kecil dan jelas yang siap untuk perubahan nyata pertama.

Menentukan kontak orang yang jelas juga membantu. Seorang tech lead atau insinyur senior dapat bertindak sebagai teman onboarding selama beberapa minggu pertama. Orang ini dapat meninjau semua perubahan awal, menjawab pertanyaan, dan menjelaskan mengapa pilihan sebelumnya terlihat seperti itu. Pemeriksaan harian singkat, bahkan lima menit di chat, dapat menjaga segala sesuatunya tetap pada jalurnya. Seorang teman yang tenang dan titik kontak yang konsisten lebih efektif untuk onboarding yang aman daripada pembicaraan besar di hari pertama. Seiring waktu, Anda dapat memindahkan lebih banyak pembaruan ke komunikasi asinkron untuk tim pengembangan, seperti catatan tertulis singkat.

Dari apa yang saya lihat, risiko terbesar selama onboarding adalah kebingungan yang diam-diam. Orang baru takut bertanya terlalu banyak, dan anggota tim lama berharap segala sesuatunya akan "klop" dengan sendirinya. Rencana onboarding yang jelas untuk pengembang eksternal dan satu orang yang bertanggung jawab atas rencana tersebut mengubah situasi ini. Ketika satu orang mengelola proses onboarding, Anda dapat mengidentifikasi pola, memperbaiki titik lemah, dan membuat setiap putaran onboarding berikutnya lebih lancar. Dalam beberapa bulan, rencana tersebut menjadi aset yang dapat diulang daripada perjuangan baru setiap kali Anda menambahkan seseorang.

Bagaimana cara menjaga kualitas kode dalam tim pengembangan campuran saat mengelola pengembang eksternal?

Anda menjaga kualitas kode dalam tim pengembangan campuran dengan menggunakan aturan, pemeriksaan, dan standar yang sama untuk semua orang. Standar Anda harus berlaku untuk semua insinyur jika Anda ingin produk terasa seperti sistem yang bersih dan aman. Begitu Anda membagi aturan berdasarkan jenis kontrak, Anda juga membagi kepercayaan dan kejelasan dalam tim Anda.

Tim pengembangan campuran adalah kelompok di mana insinyur internal dan eksternal bekerja pada produk yang sama. Mereka mungkin berada di lokasi yang berbeda, tetapi mereka berbagi satu backlog dan satu repositori kode. Campuran ini dapat sangat kuat karena menggabungkan pengetahuan domain yang mendalam dengan sudut pandang baru. Namun, campuran ini juga dapat rapuh jika setiap kelompok mengikuti kebiasaan masing-masing. Tanpa panduan yang jelas, campuran ini berubah menjadi kluster kode yang terasa berbeda dan sulit untuk berpindah di antara mereka. Itulah saat kualitas dan kecepatan mulai menurun.

Praktik terbaik tinjauan kode yang sederhana dapat membantu di sini. Setiap perubahan harus melalui tinjauan oleh setidaknya satu orang lain, terlepas dari siapa yang membuatnya. Tinjauan harus fokus pada kejelasan, keamanan, dan kesesuaian dengan sistem lainnya, bukan hanya gaya penulisan. Anda dapat mendukung ini dengan alat ringan yang memindai kode untuk masalah umum. Rutinitas ini menjaga kualitas kode pengembang eksternal sejalan dengan tim Anda secara tenang dan terulang. Orang belajar satu sama lain dan membangun pemahaman bersama tentang apa yang dianggap "baik".

Anda juga dapat melacak sejumlah kecil metrik tim pengembangan perangkat lunak. Metrik ini dapat menunjukkan berapa lama waktu yang dibutuhkan untuk menyelesaikan suatu pekerjaan, berapa banyak masalah yang sampai ke pengguna, dan seberapa sering Anda merilis. Anda tidak memerlukan puluhan angka. Anda hanya memerlukan beberapa angka yang dapat dibaca dan dibahas dengan mudah. Ketika metrik-metrik ini tetap stabil atau membaik saat Anda mengelola pengembang eksternal dan mengembangkan tim, Anda tahu bahwa sistem Anda mendukung kualitas. Jika metrik-metrik ini menurun, Anda memiliki sinyal awal untuk meninjau aturan, cakupan, atau campuran tugas Anda.

Polanya komunikasi sama pentingnya dengan aturan dan angka. Banyak tim pengembangan campuran juga termasuk dalam kategori tim agile terdistribusi karena anggota tim bekerja dari berbagai lokasi atau zona waktu. Mereka membutuhkan komunikasi asinkron untuk tim pengembangan agar kemajuan tidak bergantung pada panggilan panjang. Pembaruan tertulis singkat, catatan tugas yang jelas, dan tag sederhana untuk status sangat membantu. Pembaruan tertulis yang baik memudahkan semua insinyur untuk bergabung, mengikuti, dan meningkatkan produk seiring waktu. Pembicaraan langsung masih penting, tetapi mereka bukan lagi satu-satunya tempat di mana keputusan dibuat.

Cara Anda melibatkan orang luar juga memengaruhi kualitas. Jika Anda memperlakukan mereka sebagai aliran terpisah dengan tujuan yang tidak jelas, mereka tidak akan merasa memiliki produk sepenuhnya. Jika Anda memasukkan mereka ke dalam tim yang sudah ada di bawah satu set aturan, mereka dapat bertindak seperti anggota tim lainnya. Beberapa perusahaan menggunakan model penambahan tim untuk ini, di mana mereka menggabungkan orang internal dan eksternal di bawah satu pemimpin. Tujuan bersama, alat bersama, dan tinjauan bersama lebih berpengaruh terhadap kualitas kode dalam pengembangan perangkat lunak daripada dokumen kontrol yang berat. Seiring waktu, Anda dapat menyesuaikan campuran orang dan pekerjaan, tetapi kerangka kerja bersama tetap sama.