Dedicated Team, Staff Augmentation, atau Project-Based: Memilih Model IT Outsourcing

Ketiga model IT outsourcing menjual hal yang sama di permukaan — orang yang mengerjakan software Anda. Perbedaannya ada pada dua hal yang jarang tertulis besar di penawaran: siapa yang mengatur pekerjaan sehari-hari, dan siapa yang menanggung ketika perkiraan meleset.

Salah memilih model tidak langsung terasa. Ia muncul tiga bulan kemudian sebagai tim yang menunggu keputusan, atau sebagai perdebatan lingkup pekerjaan yang menghabiskan lebih banyak waktu daripada pekerjaannya sendiri.

Staff augmentation: Anda yang memimpin

Vendor menyediakan orang, Anda menyediakan arahan. Mereka masuk ke papan tugas Anda, mengikuti alur kerja Anda, dan dievaluasi seperti anggota tim Anda sendiri.

Cocok ketika: Anda sudah punya pemimpin teknis dan proses yang berjalan, dan yang kurang murni kapasitas. Juga cocok ketika kebutuhannya spesifik dan sementara — satu spesialis DevOps selama enam bulan, misalnya.

Bermasalah ketika: tidak ada yang punya waktu untuk mengarahkan. Developer tambahan tanpa arahan menghasilkan kode yang harus ditinjau ulang oleh orang yang sejak awal sudah kehabisan waktu, dan pada titik itu penambahan orang justru memperlambat.

Dedicated team: vendor yang memimpin, Anda menilai hasil

Vendor menyediakan tim lengkap beserta pengelolaannya — developer, QA, dan seseorang yang bertanggung jawab atas jalannya pekerjaan. Anda berurusan dengan prioritas dan hasil, bukan dengan penugasan harian.

Cocok ketika: pekerjaannya berjalan terus-menerus tanpa titik akhir yang jelas, dan Anda tidak berniat membangun kapasitas manajemen teknis di dalam. Ini juga model yang paling tahan terhadap perubahan prioritas, karena yang dikontrak adalah kapasitas, bukan daftar fitur.

Bermasalah ketika: tidak ada seorang pun di pihak Anda yang berwenang memutuskan prioritas. Tim yang menunggu keputusan tetap dibayar, dan biaya menunggu adalah biaya yang paling tidak terlihat di model ini.

Project-based: lingkup yang mengikat kedua pihak

Lingkup, tenggat, dan harga disepakati di awal. Vendor menanggung risiko perkiraan yang meleset, dan sebagai gantinya perubahan di tengah jalan diperlakukan sebagai perubahan kontrak.

Cocok ketika: yang dibutuhkan jelas dan berbatas — sistem yang sudah dipetakan, integrasi dengan cakupan tertentu, atau versi pertama sebuah produk yang alurnya sudah disepakati.

Bermasalah ketika: kebutuhannya masih dicari sambil berjalan. Setiap perubahan menjadi negosiasi, dan hubungan kerja yang tadinya kolaboratif berubah menjadi saling menjaga tafsir dokumen.

Yang perlu disepakati apa pun modelnya

• Kepemilikan kode dan akses repositori — sejak hari pertama, bukan saat kerja sama berakhir.
• Lingkungan pengembangan dan data — siapa yang menyediakan, dan data seperti apa yang boleh dipakai untuk pengujian.
• Definisi selesai — sebuah fitur dianggap selesai setelah teruji dan berjalan di lingkungan produksi, bukan setelah kodenya dikirim.
• Rencana keluar — apa yang diserahkan bila kerja sama berhenti: dokumentasi, kredensial, dan masa pendampingan.
• Kesinambungan orang — pemberitahuan bila anggota tim diganti, karena pergantian tanpa alih pengetahuan memindahkan biayanya ke Anda.

Kesalahan yang paling sering terjadi

Memilih project-based untuk pekerjaan yang sebenarnya berkelanjutan. Versi pertama selesai sesuai kontrak, lalu kebutuhan perbaikan dan penambahan datang terus-menerus sementara tidak ada kontrak yang menampungnya. Yang terjadi kemudian adalah rangkaian kontrak kecil dengan negosiasi berulang, dan setiap jeda di antaranya membuat tim vendor berpindah ke pekerjaan lain.

Jika Anda memperkirakan pekerjaannya berlanjut setelah peluncuran — dan hampir semua software berlanjut — pertimbangkan project-based untuk versi pertama dengan kesepakatan lanjutan yang sudah disiapkan sejak awal, bukan dicari setelah kontraknya habis.