Semasa membincangkan harga bagi projek perisian tersuai, unit yang paling kerap diselaraskan oleh kedua-dua pihak adalah 「man-day」: berapa ramai jurutera, berapa hari kerja, dan berapa harga satu hari. Model ini hanya berfungsi apabila keperluan stabil dan sempadan penghantaran jelas; namun apabila peraturan di tapak sering berubah, alat AI meningkatkan kecekapan pengkodan, sementara pihak A masih mengguna pakai kaedah “menambah bilangan orang” untuk tujuan pengesahan, konflik pasti akan timbul—pihak B merasakan keperluan semakin meluas, manakala pihak A pula merasakan “bilangan orang tidak bertambah, tetapi hasilnya tidak banyak”.
Isyarat dasar: daripada menjual tenaga manusia kepada menjual hasil
Pada September 2026, Kementerian Perindustrian dan Teknologi Maklumat telah menerbitkan “Pelaksanaan Rancangan Tindakan Khas ‘Kecerdasan Buatan + Perisian’”, yang beberapa kali menyebut tentang memacu transformasi model pengeluaran perisian, membangunkan “Model sebagai Perkhidmatan” dan “Agent Pintar sebagai Perkhidmatan”, serta menetapkan bahawa menjelang tahun 2028, aplikasi rujukan perisian agent pintar hendaklah dibangunkan dalam industri utama. Dokumen tersebut tidak menolak pembangunan tersuai, tetapi menyampaikan satu hala tuju yang jelas: penilaian nilai perisian semakin menitikberatkan keberkesanan sebenar, bukannya sekadar mengira jumlah man-day yang dilaburkan.
Bagi syarikat yang sedang melaksanakan ERP, MES, CRM atau sistem pengurusan industri, ini bermakna jika kontrak masih hanya mencatat “XX orang × XX hari”, selepas pelancaran mudah terjebak dalam pertikaian seperti “kod sudah siap, tetapi operasi bisnes masih tidak dapat digunakan”. Pendekatan yang lebih mampan ialah memecahkan penghantaran kepada hasil perniagaan yang boleh disahkan.
Logik perniagaan: batu loncatan harus lebih spesifik daripada man-day
Mengubah cara pembayaran projek daripada “pembayaran mengikut fasa” kepada “pembayaran mengikut batu loncatan”; setiap batu loncatan mesti memenuhi empat perkara serentak:
- Senario perniagaan: siapa yang menggunakannya, dan apa masalah operasi yang diselesaikan (contohnya “pengurus gudang mengimbas kod untuk memasukkan stok” bukannya “menyiapkan modul penyimpanan stok”).
- Kriteria data: data utama, medan status, skop kuasa yang terlibat, serta peraturan sampel yang digunakan.
- Skrip pengesahan: dengan data ujian yang diberikan, proses mana yang perlu dilalui, dokumen atau laporan apa yang dihasilkan.
- Penanganan pengecualian: bagaimana sistem memberi maklum balas apabila gagal, siapa yang berhak membuat pembetulan, dan sama ada rekod perubahan perlu diambil.
Batu loncatan tidak patut melebihi 2–4 minggu bagi satu batu loncatan; jika terlalu panjang, ia akan kembali kepada “pembangunan kotak hitam”. Contoh pemecahan yang lazim: data utama dan kuasa → gelung dokumen utama → laporan dan penyelarasan → antara muka dan peralihan pelancaran.
Logik reka bentuk: lingkungan, perubahan dan “bantuan pintar” dimasukkan ke dalam kontrak
Pengkodan bantuan AI, penghasilan kesilapan ujian secara automatik, serta dokumentasi yang dipenuhi secara pintar akan mengubah penggunaan man-day bagi fungsi yang sama, tetapi tidak secara automatik mengubah tahap kompleksiti perniagaan. Dalam kontrak dan spesifikasi keperluan, disarankan agar ditetapkan secara berasingan:
- Garis asas lingkungan (Baseline): senarai ciri + senarai perkara di luar lingkungan (Out of Scope); sebarang perubahan mesti melalui borang perubahan.
- Peraturan penentuan harga perubahan: tambahan batu loncatan dinilai berdasarkan “senario + skrip pengesahan”, bukannya menambah man-day secara sementara.
- Sempadan bantuan pintar: bahagian mana yang boleh menggunakan AI untuk meningkatkan kecekapan (penghasilan kod, draf dokumentasi), dan bahagian mana yang mesti disahkan secara manual (keselamatan, pematuhan, komitmen luar).
- Pemilikan pengetahuan yang dikumpulkan: siapa yang memegang dokumentasi proses, konfigurasi dan skrip, bagi mengelakkan gangguan operasi selepas penghantaran.
Pelaksanaan pembangunan: pengesahan automatik dan pengawasan yang boleh dilihat
Agar pendekatan “berorientasikan hasil” dapat dilaksanakan, pihak teknikal perlu bekerjasama dalam tiga perkara:
- Memasukkan kes-kes pengesahan ke dalam pangkalan data: setiap batu loncatan mempunyai satu set kes-kes automatik atau separa automatik, yang boleh dijalankan semula untuk tujuan semakan.
- Pengasingan persekitaran dan data: data persekitaran UAT boleh dikosongkan semula, bagi mengelakkan situasi “hanya berjaya di persekitaran demo”.
- Log pengawasan yang boleh dilihat: operasi penting mempunyai log audit, membolehkan penjejakan siapa yang membuat perubahan apabila berlaku pertikaian.
Jika projek merangkumi agent pintar atau enjin peraturan, pengesahan hendaklah turut disertakan dengan mekanisme pemeriksaan secara rawak: memasukkan kes-kes sempadan secara rawak, memeriksa sama ada penolakan jawapan, peningkatan kepada manusia, atau halangan kuasa mematuhi reka bentuk, bukannya hanya melihat “mampu berkomunikasi”.
Tiga jenis pertikaian yang biasa berlaku dan langkah pencegahan
Pertikaian pertama: “Semua fungsi telah siap, tetapi mengapa perniagaan masih tidak menggunakannya?”—Pencegahan: batu loncatan hendaklah disepadukan dengan operasi jawatan dan daftar hadir latihan; semasa pengesahan, pihak B hendaklah melakukan lawatan ke lokasi, bukannya sekadar mempamerkan PPT.
Pertikaian kedua: “Mengapa perlu bayar lebih untuk menambah satu keperluan kecil?”—Pencegahan: borang perubahan hendaklah menjelaskan batu loncatan, skrip dan tempoh kerja yang terjejas; kedua-dua pihak hendaklah menandatangani sebelum pembangunan dilaksanakan.
Pertikaian ketiga: “AI telah meningkatkan kecekapan, bolehkah man-day dikurangkan?”—Pencegahan: kontrak hendaklah membezakan antara “kos pencapaian” dan “kompleksiti perniagaan”; manfaat peningkatan kecekapan boleh dicerminkan dalam jumlah keseluruhan atau tempoh, tetapi piawaian pengesahan tidak boleh dikurangkan.
Cadangan percubaan: bermula dengan satu modul tertutup
Tidak perlu menunggu seluruh sistem menulis semula kontrak. Pilih satu modul yang boleh ditutup dalam 2–3 minggu (seperti urusan masuk-keluar stok, laporan kerja, kelulusan kos), gunakan templat baharu untuk menandatangani perjanjian tambahan: senaraikan senario, skrip, pengecualian dan titik pembayaran. Setelah berjaya, barulah perlu diperluas ke seluruh projek. Untuk menilai kejayaan, lihat sama ada borang perubahan dapat mengurangkan masa pertikaian, dan sama ada kadar kelulusan UAT pada percubaan pertama meningkat, bukannya melihat berapa banyak man-day yang kurang dilaporkan oleh pihak B. Jika modul percubaan dipilih dengan baik, maka perubahan kontrak bagi keseluruhan projek akan menjadi lebih meyakinkan.
Man-day tidak akan lenyap dalam semalam, tetapi ia sedang berubah daripada “unit penetapan harga tunggal” kepada “rujukan anggaran kos”. Menulis batu loncatan dan skrip pengesahan ke dalam kontrak merupakan kemahiran asas bagi memastikan perisian tersuai masih mampu menghantar hasil yang boleh dipercayai dalam konteks “kecerdasan buatan + perisian”.
Kerjasama dengan harga tetap dan iterasi agil
Pengesahan batu loncatan tidak menolak pendekatan agil: setiap Sprint masih boleh menghantar increment yang boleh dipamerkan, tetapi pembayaran dan pengesahan rasmi masih bergantung pada batu loncatan yang lebih besar. Kontrak harga tetap khususnya perlu menjelaskan “titik pembekuan lingkungan”—selepas mana评审 berlaku, keperluan tambahan hendaklah melalui borang perubahan, bagi mengelakkan penambahan fungsi secara lisan. Bagi modul yang merangkumi agent pintar, disarankan agar pengesahan batu loncatan diadakan secara berasingan untuk “versi peraturan + kadar kelulusan pemeriksaan”, bukannya disatukan dengan pelancaran keseluruhan stesen.
Data industri menunjukkan bahawa kira-kira satu pertiga projek perisian gagal disebabkan oleh kekeliruan dalam keperluan dan kriteria pengesahan, bukannya masalah teknikal semata-mata. Lebih bernilai jika terlebih dahulu menetapkan “apakah yang dianggap siap” dalam kontrak, berbanding berdebat sama ada AI telah menggantikan beberapa orang jurutera. Pada kali berikutnya semasa mesyuarat penilaian projek, bolehlah diajukan soalan: jika esok semua pekerja pihak B bercuti, adakah kita masih boleh menilai sama ada batu loncatan semasa mencapai piawaian melalui skrip—jika tidak dapat dijawab, bermakna pengesahan belum ditetapkan dengan jelas. Penulisan batu loncatan ke dalam kontrak bukan bertujuan menyusahkan pihak B, tetapi supaya kedua-dua pihak berbincang di atas kertas yang sama tentang “adakah kerja sudah siap”. Hal ini amat penting terutama dalam projek yang menunjukkan peningkatan kecekapan akibat AI, maka perlu ditegaskan lebih awal.