Cara Membentuk Tim Pengembangan Khusus dalam 30 Hari

Pendahuluan

Sebagian besar kontrak outsourcing gagal pada bulan pertama, bukan pada tahun pertama. Para insinyur memang berkualifikasi dan tarifnya wajar, tetapi tim tersebut menghabiskan waktu berminggu-minggu tanpa akses, konteks, atau prioritas yang jelas. Pada saat pekerjaan dimulai, klien sudah kehilangan kepercayaan terhadap model tersebut.

Tim pengembangan khusus dapat mencapai produktivitas penuh dalam waktu 30 hari jika klien telah mempersiapkannya. Vendor menangani perekrutan dan perekrutan, tetapi hanya klien yang dapat menjelaskan produk, basis kode, dan tujuan bisnis. Orientasi adalah proyek bersama, dan pihak klien memikul sebagian besar tanggung jawab dalam transfer pengetahuan.

Sebelum Hari Pertama: Apa yang Harus Disiapkan

Minggu sebelum tanggal mulai menentukan seberapa cepat tim bergerak. Insinyur yang menunggu tiga hari untuk akses ke repositori akan kehilangan momentum, dan penundaan tersebut menentukan suasana kerja sama secara keseluruhan.

Persiapan membutuhkan beberapa jam kerja dari pihak klien. Sebagian besar bersifat administratif, dan satu orang dapat menangani seluruh daftar tersebut.

• Akses dan akun. Buat akun untuk repositori kode, pelacak tugas, konsol cloud, dan saluran komunikasi. Uji setiap login sebelum tanggal mulai.
• Dokumentasi teknis. Kumpulkan diagram arsitektur, deskripsi API, dan panduan pengaturan di satu tempat. Dokumen yang sudah usang dapat diterima asalkan ada yang menandai bagian yang telah berubah.
• Kontak utama. Tunjuk satu orang di pihak klien yang menjawab pertanyaan dalam satu hari kerja. Orang ini biasanya adalah pemimpin teknis atau pemilik produk.
• Backlog awal. Siapkan 10 hingga 15 tugas dengan tingkat kompleksitas rendah dan sedang. Tim membutuhkan pekerjaan yang mengajarkan basis kode tanpa risiko terhadap produksi.

Minggu 1: Akses, Konteks, dan Tugas Pertama

Minggu pertama difokuskan pada orientasi. Tim mempelajari fungsi produk, siapa yang menggunakannya, dan bagaimana kode diorganisasikan.

Hasil yang dihasilkan pada minggu ini memang dirancang agar sedikit. Tujuannya adalah menciptakan lingkungan kerja dan penggabungan perubahan pertama, bukan peluncuran fitur.

Hari 1–2: Penyiapan Lingkungan

Pada hari pertama, klien mengadakan panggilan awal. Pemilik produk menjelaskan model bisnis, kelompok pengguna utama, dan prioritas saat ini. Pemimpin teknis memaparkan arsitektur dan proses penerapan.

Setelah panggilan tersebut, para insinyur menyiapkan lingkungan lokal dan menjalankan aplikasi. Sebagian besar masalah penyiapan muncul di sini, sehingga kontak klien harus tetap tersedia untuk memberikan jawaban dengan cepat.

Hari ke-3–5: Tugas Kecil Pertama

Setiap insinyur mengambil satu atau dua tugas dari backlog awal. Perbaikan bug, perubahan UI kecil, dan cakupan pengujian cocok dilakukan pada tahap ini. Mereka menyentuh kode yang sebenarnya tetapi risikonya rendah.

Setiap tugas melalui siklus lengkap tinjauan kode, pengujian, dan penerapan. Hal ini menunjukkan kepada tim bagaimana klien bekerja dan mengungkap celah dalam proses sejak dini.

Minggu ke-2: Proses dan Ritme Komunikasi

Pada minggu kedua, tim beralih dari tugas individu ke rutinitas tim. Klien dan vendor menyepakati cara perencanaan, pembahasan, dan pelaporan pekerjaan.

Tim yang tersebar membutuhkan struktur yang lebih ketat daripada tim yang berada di lokasi yang sama. Perbedaan zona waktu dan budaya membuat komunikasi informal menjadi lebih sulit, sehingga ritme komunikasi harus ditetapkan secara eksplisit.

• Rapat harian. Adakan panggilan singkat pada waktu yang tumpang tindih di kedua zona waktu. Lima belas menit sudah cukup untuk membahas status dan hambatan.
• Perencanaan sprint. Rencanakan pekerjaan dalam sprint satu atau dua minggu. Pemilik produk klien menetapkan prioritas, dan tim memperkirakan upaya yang diperlukan.
• Aturan tinjauan kode. Sepakati siapa yang meninjau apa dan seberapa cepat. Penundaan tinjauan lebih dari satu hari akan memperlambat seluruh tim.
• Pembaruan tertulis. Mintalah ringkasan mingguan singkat di saluran bersama. Hal ini memberikan visibilitas kepada pemangku kepentingan tanpa perlu rapat tambahan.
• Jalur eskalasi. Tentukan siapa yang menangani hambatan di masing-masing pihak. Manajer akun vendor menangani masalah tim, sedangkan kontak klien menangani pertanyaan terkait produk.

Minggu 3–4: Kepemilikan dan Pengukuran

Dua minggu terakhir menguji apakah proses orientasi berjalan dengan baik. Tim mengambil tanggung jawab yang sesungguhnya, dan kedua belah pihak mengevaluasi hasilnya berdasarkan kriteria yang jelas.

Tahap ini juga menunjukkan di mana proses tersebut masih perlu disesuaikan. Masalah kecil lebih mudah diperbaiki pada hari ke-25 daripada pada hari ke-90.

Menyerahkan Fitur Nyata

Pada minggu ketiga, berikan satu fitur lengkap dari peta jalan produk kepada tim. Fitur tersebut harus memerlukan keputusan desain, melibatkan beberapa bagian dari basis kode, dan rilis produksi.

Pimpinan teknis klien meninjau pendekatan teknis sebelum pengembangan dimulai. Setelah itu, tim bertanggung jawab penuh atas pekerjaan tersebut mulai dari perkiraan hingga penerapan. Pengawasan yang ketat pada tahap ini justru akan mengalahkan tujuannya.

Metrik yang Perlu Dipantau pada Hari ke-30

Di akhir bulan, adakan rapat evaluasi dengan vendor. Bandingkan hasilnya dengan ekspektasi yang ditetapkan pada minggu pertama, dan gunakan angka-angka jika memungkinkan.

• Kecepatan pengiriman. Bandingkan poin cerita yang direncanakan dan yang telah diselesaikan selama dua sprint terakhir. Kecepatan yang stabil lebih penting daripada kecepatan yang tinggi.
• Kualitas kode. Periksa persentase pull request yang lolos tinjauan pada putaran pertama atau kedua. Perbaikan yang sering menandakan adanya kesenjangan dalam konteks.
• Volume pertanyaan. Lacak seberapa sering insinyur meminta bantuan kepada klien. Angka ini seharusnya menurun setiap minggu.
• Umpan balik pemangku kepentingan. Mintalah penilaian singkat dari pemilik produk dan pemimpin teknis. Pandangan mereka sering kali mengungkap masalah yang terlewatkan oleh metrik.

Kesalahan Umum dalam Onboarding

Sebagian besar penundaan onboarding disebabkan oleh beberapa hal yang sama. Perusahaan sering mengulanginya karena masing-masing masalah tampak sepele pada awalnya.

• Akses yang terlambat. Akun yang baru tiba pada hari ketiga membuat tim kehilangan waktu tiga hari. Persetujuan keamanan sering kali memakan waktu lebih lama dari yang diharapkan, jadi mulailah prosesnya sejak dini.
• Tidak ada konteks produk. Insinyur yang tidak memahami pengguna akan membuat keputusan yang secara teknis benar tetapi tidak berguna. Satu jam penjelasan tentang produk dapat menghemat waktu pengerjaan ulang selama berminggu-minggu.
• Terlalu banyak kontak. Ketika lima orang memberikan instruksi, prioritas menjadi bertentangan. Satu pengambil keputusan menjaga arah tetap jelas.
• Memperlakukan tim sebagai pihak eksternal. Saluran komunikasi yang terpisah dan pertemuan yang dibatasi menciptakan struktur dua tingkat. Tim yang mengikuti rutinitas klien akan berintegrasi lebih cepat.

Catatan Akhir

Tiga puluh hari sudah cukup untuk membawa tim yang berdedikasi mencapai produktivitas penuh. Hasilnya tidak terlalu bergantung pada vendor, melainkan lebih pada seberapa baik klien mempersiapkan akses, konteks, dan prioritas yang jelas.

Anggaplah proses onboarding sebagai sebuah proyek dengan penanggung jawab, tenggat waktu, dan tinjauan akhir. Bulan pertama yang terstruktur akan membangun kepercayaan yang dibutuhkan dalam kerja sama jangka panjang.