Onboarding Developer Baru Tanpa Menyita Waktu Tim

Setiap kali ada developer baru bergabung, ada satu pertanyaan yang selalu saya ajukan ke diri sendiri: berapa lama sampai orang ini bisa jalanin proyek di laptopnya sendiri tanpa nanya-nanya? Di tim kecil, terutama yang menangani sistem klinik atau rumah sakit dengan banyak integrasi, jawaban yang — sebagai ilustrasi — sampai "tiga hari" itu sudah mahal. Bukan cuma mahal buat developer baru yang jadi frustrasi, tapi juga buat tim inti yang waktunya kesedot buat jawab pertanyaan yang sebenarnya bisa dijawab dokumentasi. Onboarding yang baik itu bukan soal seremoni penyambutan, tapi soal desain sistem: environment yang bisa nyala sendiri dan dokumentasi yang bisa dibaca sendiri.

Environment yang reproducible, bukan yang diwariskan turun-temurun

Masalah klasik onboarding adalah environment development yang cuma hidup di kepala satu-dua orang senior. Ada langkah manual yang "gampang kok tinggal install ini itu", tapi ternyata bergantung pada versi PHP tertentu, extension tertentu, atau konfigurasi lokal yang nggak pernah ditulis di mana pun. Solusinya, menurut saya, adalah mengunci environment ke dalam kode, bukan ke dalam ingatan orang.

Pakai container untuk semua service yang bisa di-containerize — database, cache, queue worker, bahkan PHP-nya sendiri. Developer baru cukup git clone, jalankan satu perintah, dan environment yang sama persis dengan yang dipakai produksi (atau minimal yang dipakai tim) langsung tersedia. Sebagai ilustrasi struktur yang biasa saya pakai:

docker compose up -d
docker exec -it app cp .env.example .env
docker exec -it app php artisan key:generate
docker exec -it app php artisan migrate --seed

Poin pentingnya bukan perintah spesifik ini, tapi prinsipnya: satu file docker-compose.yml dan satu skrip setup harus jadi satu-satunya sumber kebenaran soal cara menyalakan proyek. Kalau ada langkah yang dijelaskan lewat chat atau ngobrol langsung tapi tidak pernah masuk ke skrip, anggap saja langkah itu akan hilang begitu orang yang tahu sedang cuti atau resign.

Seed data yang bermakna, bukan database kosong

Environment yang nyala tapi datanya kosong tetap bikin developer baru mentok di hari pertama, karena dia tidak bisa lihat perilaku aplikasi yang sebenarnya. Saya biasa menyiapkan seeder yang menghasilkan data dummy yang representatif — bukan data produksi asli, tapi data fiktif yang bentuknya mirip: ada beberapa akun dengan role berbeda, ada beberapa record transaksi dengan status yang bervariasi, sehingga fitur-fitur utama bisa langsung dicoba tanpa harus tahu dulu cara input manual dari nol.

Untuk sistem yang berurusan dengan data sensitif seperti rekam medis, aturan mainnya harus jelas dari awal: seeder untuk lingkungan development hanya boleh berisi data sintetis, tidak pernah salinan dari data nyata. Ini bukan cuma soal kepatuhan, tapi juga soal keamanan — developer baru tidak perlu, dan tidak boleh, memegang data pasien sungguhan hanya demi bisa mulai ngoding.

Dokumentasi yang dijawab sistem, bukan orang

Bagian yang paling sering diabaikan adalah dokumentasi "kenapa", bukan cuma "bagaimana". README yang bagus tidak cuma berisi daftar perintah instalasi, tapi juga peta singkat: apa saja modul utama, di mana letak business logic yang paling sering disentuh, dan konvensi apa yang dipakai tim — misalnya soal penamaan branch, alur review, atau pola pemakaian Filament untuk admin panel. Saya suka menaruh dokumen singkat berisi "keputusan arsitektur" — kenapa dipilih pendekatan tertentu, bukan yang lain — supaya developer baru tidak mengulang perdebatan yang sudah pernah selesai.

Checklist hari pertama juga membantu banget, dan ini bisa berupa dokumen sesederhana daftar tercentang: clone repo, jalankan environment, jalankan test suite, buka satu halaman di browser, buat satu pull request kecil (misalnya perbaikan typo atau penambahan test) sebagai latihan alur kerja tim. Ide di balik pull request pertama yang kecil ini adalah supaya developer baru merasakan seluruh siklus — branch, commit, review, merge — tanpa tekanan harus langsung mengerjakan fitur besar.

Satu kebiasaan yang saya pegang: setiap kali ada pertanyaan berulang dari developer baru, itu sinyal ada lubang di dokumentasi. Alih-alih hanya menjawab di chat, saya coba tambahkan jawabannya ke README atau wiki internal. Lama-lama, dokumentasi ini jadi "developer virtual" yang menjawab sebagian besar pertanyaan dasar, dan waktu tim senior bisa dipakai untuk hal yang benar-benar butuh diskusi — desain fitur, trade-off arsitektur, bukan cara menyalakan Docker.

Takeaway

Onboarding yang cepat itu bukan hasil dari orang yang sabar menjawab pertanyaan, tapi hasil dari sistem yang didesain supaya sebagian besar pertanyaan itu tidak perlu ditanyakan. Investasikan waktu di environment yang reproducible lewat container, seed data yang representatif tapi aman, dan dokumentasi yang terus diperbarui setiap kali ada celah yang ketahuan. Begitu fondasi ini ada, developer baru bisa mulai berkontribusi nyata di hari pertama — dan tim inti bisa tetap fokus ke pekerjaan yang membutuhkan pemikiran mereka, bukan jadi buku panduan berjalan.