Tim Developer Dedicated atau Proyek Fixed Price: Mana yang Cocok?

Kebanyakan perusahaan yang meng-outsource pengembangan software memulai dengan proyek fixed price: scope ditentukan, harga disepakati, tanggal selesai ditetapkan. Model ini berjalan baik untuk versi pertama dengan kebutuhan yang jelas. Masalahnya muncul ketika produk terus berkembang, prioritas berubah setiap bulan, dan setiap perubahan jadi negosiasi baru. Tim dedicated adalah model yang memang dibuat untuk kondisi seperti itu. Artikel ini membahas cara kerjanya, kapan cocok dipakai, dan bagaimana mendapatkan hasil dari bulan pertama.

Tiga Model Kerja Sama yang Umum

Tanda Tim Dedicated Cocok untuk Anda

• Aplikasi sudah live dan terus butuh fitur baru, perbaikan, dan integrasi.
• Roadmap berubah mengikuti masukan pengguna atau kondisi bisnis, sehingga scope yang dikunci akan basi dalam beberapa minggu.
• Anda butuh lebih banyak developer daripada yang bisa direkrut dengan cepat, atau keahlian tertentu yang belum ada di internal.
• Pekerjaannya cukup untuk minimal enam bulan, sehingga waktu untuk onboarding tidak terbuang.
• Ada orang di perusahaan Anda yang bisa jadi product owner dan mengambil keputusan soal prioritas setiap minggu.

Poin terakhir paling sering terlewat. Kecepatan tim dedicated bergantung pada kecepatan keputusan yang mereka terima. Kalau product owner sulit dihubungi, tim akan menunggu, menebak-nebak, atau membangun hal yang salah, dan biaya bulanan tetap berjalan.

Susunan Tim yang Umum

Susunan tim mengikuti kebutuhan produk. Untuk produk web dan mobile, titik awal yang umum adalah dua backend developer, satu atau dua frontend atau mobile developer, satu QA engineer, dan tech lead yang bisa saja dibagi dengan tim lain. Desain, DevOps, dan manajemen proyek sering ditambahkan secara paruh waktu. Mulai dari tim kecil, lalu tambah orang setelah ritme kerjanya stabil. Menambah anggota ke tim yang masih mempelajari codebase biasanya justru memperlambat selama beberapa minggu.

Bulan Pertama: Onboarding

1. 1Berikan akses ke repository, environment, issue tracker, dan kanal komunikasi di hari-hari pertama, supaya tim tidak menunggu proses persetujuan.
2. 2Jelaskan arsitektur, alur bisnis utama, dan bagian sistem yang sering bermasalah, langsung dari orang yang membangunnya.
3. 3Mulai dengan tugas kecil yang nyata seperti perbaikan bug, supaya tim mempelajari codebase dan proses deploy dengan risiko rendah.
4. 4Sepakati ritme kerja: panjang sprint, planning, update harian, demo, dan cara menangani masalah mendesak.
5. 5Evaluasi setelah empat minggu: apa yang memperlambat tim, pengetahuan apa yang masih kurang, dan apakah susunan timnya sudah tepat.

Ukur Hasil Kerja Tim

Timesheet hanya menunjukkan bahwa orang-orangnya bekerja. Timesheet tidak menunjukkan apakah produknya membaik. Ukuran yang lebih berguna adalah apakah target sprint tercapai, berapa lama perubahan yang sudah disetujui sampai ke production, berapa banyak bug yang lolos ke pengguna, dan seberapa cepat insiden diselesaikan. Lihat trennya selama beberapa sprint, lalu bahas angkanya bersama tim supaya angka itu membantu menemukan hambatan.

Yang Perlu Masuk ke Kontrak

• Nama anggota tim dan perannya, beserta hak Anda untuk mewawancarai dan menyetujui pengganti.
• Masa pemberitahuan untuk menambah atau mengurangi anggota tim, dan seberapa cepat anggota baru bisa bergabung.
• Cara menangani cuti, libur, dan penggantian anggota, termasuk masa serah terima kalau ada yang keluar.
• Kepemilikan source code dan hak kekayaan intelektual, dengan repository dan akun cloud atas nama perusahaan Anda.
• Jam kerja yang beririsan, kanal komunikasi, dan waktu respons yang diharapkan saat ada insiden di production.
• Ketentuan berakhirnya kerja sama: dokumentasi dan proses serah terima kalau kontrak selesai.

Kesalahan yang Sering Terjadi

• Memperlakukan tim seperti antrean tiket, tanpa menjelaskan tujuan bisnis di balik pekerjaannya.
• Membagi tim ke terlalu banyak proyek yang tidak saling berhubungan, sehingga tidak ada yang benar-benar memahami satu pun.
• Menjauhkan tim dari pengguna dan data production, sehingga setiap keputusan hanya berdasarkan cerita orang lain.
• Melewatkan code review dan test otomatis supaya lebih cepat, lalu menanggung akibatnya dalam bentuk bug beberapa bulan kemudian.
• Membiarkan semua pengetahuan ada di vendor, tanpa ada orang internal yang memahami arsitekturnya.

Undang tim dedicated ke sprint review yang sama dengan stakeholder internal Anda. Melihat langsung reaksi bisnis terhadap sebuah fitur memberi developer konteks yang tidak bisa didapat dari deskripsi tiket.

Menggabungkan Beberapa Model

Model-model ini bisa digabung. Jalur yang umum adalah membangun versi pertama sebagai proyek fixed price, lalu melanjutkan pengembangan dengan tim dedicated yang lebih kecil. Pilihan lain, tim inti internal memegang arsitektur dan keputusan produk, sementara tim dedicated menangani area tertentu seperti aplikasi mobile atau integrasi. Pilih model yang sesuai dengan tahap produk saat ini, lalu tinjau lagi seiring produknya berkembang.