Saat menawar proyek pengembangan perangkat lunak kustom, unit yang paling sering diselaraskan oleh kedua belah pihak adalah“man-day”: berapa banyak insinyur, berapa hari kerja, dan berapa harga per unitnya. Model ini hanya dapat berjalan dengan baik ketika kebutuhan stabil dan batas pengiriman jelas; namun begitu aturan di lapangan sering berubah, alat AI meningkatkan efisiensi pengkodean, sementara pihak A masih melakukan验收 berdasarkan “penumpukan orang”, maka konflik pun akan muncul—pihak B merasa kebutuhan berkembang pesat, sedangkan pihak A merasa “jumlah orang tidak bertambah, tetapi hasilnya tidak lebih baik”.
Sinyal kebijakan: dari menjual tenaga manusia ke menjual hasil akhir
Pada September 2026, Kementerian Perindustrian dan Teknologi Informasi mengeluarkan “Rencana Pelaksanaan Tindakan Khusus ‘Kecerdasan Buatan + Perangkat Lunak’”, yang beberapa kali menyebutkan upaya mendorong transformasi model produksi perangkat lunak, mengembangkan “Model sebagai Layanan” dan “Agent Cerdas sebagai Layanan”, serta secara tegas menetapkan bahwa pada tahun 2028 harus dibangun aplikasi percontohan perangkat lunak agent cerdas di industri-industri utama. Dokumen tersebut tidak menolak pengembangan kustom, tetapi menyampaikan arah yang jelas:dalam menilai nilai perangkat lunak, semakin ditekankan pada hasil nyata, bukan sekadar berapa banyak man-day yang telah diinvestasikan。
Bagi perusahaan yang sedang mengembangkan ERP, MES, CRM, atau sistem manajemen industri, hal ini berarti jika kontrak masih hanya mencantumkan “XX orang × XX hari”, setelah peluncuran sistem sangat mudah terjebak dalam perselisihan seperti “kode sudah selesai, tetapi bisnis tidak bisa digunakan”. Cara yang lebih berkelanjutan adalah membagi deliverables menjadihasil bisnis yang dapat diverifikasi。
Logika bisnis: milestone harus lebih spesifik daripada man-day
Meningkatkan metode pembayaran proyek dari “pembayaran per tahap” menjadi “pembayaran berdasarkan milestone”; setiap milestone harus memenuhi empat syarat sekaligus:
- Skenario bisnis: siapa yang menggunakannya, operasi apa yang diselesaikan (misalnya “petugas gudang memindai kode untuk masuk barang” bukan “menyelesaikan modul penerimaan barang”).
- Standar data: data master apa saja yang terlibat, bidang status dan ruang lingkup hak akses, serta aturan samplingnya.
- Skrip verifikasi: dengan data uji tertentu, proses apa saja yang harus dilalui, dokumen atau laporan apa yang dihasilkan.
- Penanganan pengecualian: bagaimana sistem memberikan notifikasi saat terjadi kegagalan, siapa yang berhak melakukan perubahan, apakah ada jejak log.
Milestone sebaiknya tidak lebih dari2–4 minggu; jika terlalu panjang, risiko kembali ke “pengembangan kotak hitam” akan meningkat. Contoh pemecahan umum: data master dan hak akses → siklus tertutup dokumen inti → laporan dan rekonsiliasi → antarmuka dan peralihan go-live.
Logika desain: cakupan, perubahan, dan “bantuan cerdas” dimasukkan ke dalam kontrak
Pengkodean bantuan AI, generasi otomatis kasus uji, serta pengisian dokumen secara cerdas akan mengubah konsumsi man-day untuk fungsi yang sama, tetapitidak secara otomatis mengubah kompleksitas bisnis. Dalam kontrak dan spesifikasi kebutuhan, disarankan untuk mencantumkan secara terpisah:
- Baseline cakupan (Baseline): daftar fitur + daftar yang tidak termasuk dalam cakupan (Out of Scope); setiap perubahan harus melalui formulir perubahan.
- Aturan penetapan harga perubahan: penambahan milestone dinilai berdasarkan “skenario + skrip verifikasi”, bukan penambahan man-day secara mendadak.
- Batas bantuan cerdas: bagian mana yang dapat dioptimalkan dengan AI (generasi kode, draf dokumen), dan bagian mana yang tetap memerlukan tanda tangan manual (keamanan, kepatuhan, komitmen eksternal).
- Hak kepemilikan pengetahuan yang terkumpul: siapa yang memegang dokumentasi proses, konfigurasi, dan skrip, guna menghindari terjadinya kesenjangan operasional pasca-pengiriman.
Implementasi pengembangan: otomatisasi verifikasi dan observabilitas
Agar “berorientasi hasil” dapat dijalankan, sisi teknis perlu mendukung tiga hal:
- Masukan kasus verifikasi ke dalam database: setiap milestone memiliki satu set kasus verifikasi otomatis atau semi-otomatis, yang dapat dijalankan ulang secara berkala.
- Isolasi lingkungan dan data: data lingkungan UAT dapat direset, sehingga menghindari situasi “hanya bisa lolos di lingkungan demo”.
- Log observabilitas: operasi kunci dilengkapi log audit, sehingga saat terjadi perselisihan dapat ditelusuri siapa yang mengubah apa.
Jika proyek mencakup agent cerdas atau mesin aturan, verifikasi harus menambahkanmekanisme inspeksi acak: memasukkan contoh kasus batas secara acak, memeriksa apakah penolakan jawaban, peningkatan ke level manual, atau pemblokiran hak akses sesuai dengan desain, bukan sekadar melihat apakah “bisa ngobrol”.
Tiga jenis perselisihan umum dan cara pencegahannya
Perselisihan pertama: “Semua fitur sudah dibuat, mengapa bisnis tidak menggunakannya?”—Pencegahan: mengaitkan milestone dengan tugas jabatan dan absensi pelatihan, serta melakukan inspeksi langsung di lokasi saat verifikasi, bukan sekadar presentasi PPT.
Perselisihan kedua: “Mengapa harus membayar tambahan untuk permintaan kecil?”—Pencegahan: dalam formulir perubahan harus dicantumkan dengan jelas milestone, skrip, dan durasi yang terdampak; kedua belah pihak menandatangani baru kemudian melanjutkan pengembangan.
Perselisihan ketiga: “AI telah meningkatkan efisiensi, apakah man-day bisa dikurangi?”—Pencegahan: kontrak membedakan antara “biaya realisasi” dan “kompleksitas bisnis”; manfaat efisiensi dapat tercermin dalam total harga atau periode, tetapi standar verifikasi tidak boleh diturunkan.
Rekomendasi pilot: mulai dari satu modul tertutup
Tidak perlu menunggu seluruh sistem menulis ulang kontrak. Pilih satu modul yang dapat ditutup dalam2–3 minggu(seperti penerimaan dan pengiriman barang, laporan pekerjaan, atau persetujuan biaya), lalu gunakan template baru untuk menandatangani perjanjian tambahan: cantumkan skenario, skrip, pengecualian, dan titik pembayaran. Setelah berhasil dijalankan, barulah diperluas ke seluruh proyek. Untuk menilai keberhasilan, lihat apakahjumlah formulir perubahan yang mengurangi waktu perselisihan、meningkatkan tingkat kelulusan UAT dalam sekali percobaan—bukan berapa banyak man-day yang kurang dilaporkan oleh pihak B. Jika modul percontohan dipilih dengan baik, maka perubahan kontrak untuk seluruh proyek akan lebih meyakinkan.
Man-day tidak akan hilang dalam semalam, tetapi ia sedang bertransformasi dari “satuan penetapan harga tunggal” menjadi “referensi perkiraan biaya”. Menuliskan milestone dan skrip verifikasi ke dalam kontrak adalah keterampilan dasar agar pengembangan perangkat lunak kustom tetap dapat menghasilkan hasil yang dapat dipercaya dalam konteks “kecerdasan buatan + perangkat lunak”.
Koordinasi dengan kontrak harga tetap dan iterasi agile
Verifikasi berdasarkan milestone tidak menolak pendekatan agile: setiap Sprint tetap dapat mengirimkan increment yang dapat didemonstrasikan, tetapipembayaran dan verifikasi resmitetap bergantung pada milestone yang lebih besar. Kontrak harga tetap khususnya harus secara jelas mencantumkan “titik pembekuan cakupan”—setelah review kali mana permintaan tambahan harus melalui formulir perubahan, guna menghindari penambahan fitur secara lisan. Untuk modul yang mengandung agent cerdas, disarankan melakukan verifikasi milestone terpisah untuk “versi aturan + tingkat kelulusan inspeksi acak”, jangan digabungkan dengan peluncuran seluruh situs dalam satu paket.
Data industri menunjukkan bahwa sekitarsepertigaproyek perangkat lunak gagal karena ketidakjelasan cakupan kebutuhan dan verifikasi, bukan karena implementasi teknis itu sendiri. Lebih baik menuliskan terlebih dahulu “apa yang dianggap selesai” dalam kontrak daripada berdebat tentang berapa banyak programmer yang digantikan oleh AI. Pada review perencanaan berikutnya, bisa mulai dengan pertanyaan: jika besok semua staf pihak B libur, bisakah kita menilai apakah milestone saat ini telah memenuhi standar hanya berdasarkan skrip—jika tidak bisa menjawab, berarti verifikasi belum ditulis dengan jelas. Menuliskan milestone ke dalam kontrak bukan untuk menyulitkan pihak B, melainkan agar kedua belah pihak dapat berdiskusi di atas lembaran yang sama tentang “apakah sudah selesai atau belum”. Hal ini semakin penting untuk proyek-proyek yang efisiensi AI-nya semakin jelas, sehingga harus dijelaskan lebih awal.