Selepas sepuluh tahun membina sistem untuk organisasi di Malaysia, corak kegagalan yang sama berulang. Kelimanya boleh dielakkan sepenuhnya dengan soalan yang ditanya sebelum wang bertukar tangan.
1. Kod sumber bukan milik anda
Ini yang paling mahal, dan ia hanya kelihatan apabila anda mahu berpindah.
Anda membayar RM15,000 untuk sistem. Dua tahun kemudian anda mahu menambah ciri, tetapi pembangun asal sudah tidak dapat dihubungi. Anda hubungi orang lain. Soalan pertama mereka: "Boleh hantar kod sumber?" Anda tidak ada. Ia berada di akaun peribadi seseorang.
Anda tidak membeli sistem. Anda menyewanya, tanpa menyedarinya.
Cara elak
- Nyatakan dalam kontrak: hak milik penuh kod sumber berpindah kepada anda selepas pembayaran akhir.
- Minta akses repositori — tempat kod disimpan dalam talian, biasanya GitHub, GitLab atau Bitbucket — dan bukan sekadar fail zip yang dihantar melalui WhatsApp. Repositori menyimpan sejarah setiap perubahan: siapa mengubah apa dan bila. Pembangun seterusnya boleh membaca sejarah itu untuk memahami sistem anda dalam beberapa jam, berbanding beberapa minggu.
- Uji sebelum pembayaran akhir: minta seseorang selain pembangun asal memuat turun dan menjalankannya.
2. Akaun didaftarkan atas nama vendor
Domain, hosting, akaun Google Play, gerbang pembayaran. Kalau mana-mana daripada ini atas nama vendor, mereka memegang suis.
Kes yang paling menyakitkan: nama domain. Kalau domain atas nama vendor dan hubungan menjadi masam, mereka boleh mematikan laman anda dan semua emel syarikat pada hari yang sama. Memulihkannya boleh mengambil masa berbulan.
Cara elak
- Daftar domain sendiri, dengan kad anda, sebelum projek bermula. Beri vendor akses, bukan pemilikan.
- Cipta akaun hosting atas nama syarikat anda. Jemput vendor sebagai pengguna tambahan.
- Akaun store mesti atas nama anda. Aplikasi yang tersiar di bawah akaun vendor bukan milik anda.
- Akaun gerbang pembayaran mesti atas nama anda — wang pelanggan masuk ke situ.
- Simpan senarai semua akaun dan siapa yang memegang aksesnya. Semak setiap enam bulan.
3. Skop tidak bertulis
"Buatkan sistem tempahan" bukan skop. Ia harapan, dan dua pihak akan membayangkan dua benda berbeza.
Corak biasa: anda membayangkan pelanggan boleh membatalkan tempahan sendiri. Vendor tidak. Tiga bulan kemudian anda bertanya di mana butang batal. Mereka berkata itu di luar skop. Kedua-dua pihak betul, dan kedua-duanya rugi.
Cara elak
- Tulis senarai skrin dan siapa yang boleh melihat setiap satu.
- Untuk setiap tindakan, tulis siapa boleh membuatnya dan apa yang berlaku selepas itu. "Pelanggan boleh batal sehingga 24 jam sebelum masa tempahan, dan deposit dipulangkan" — itu skop.
- Senaraikan secara jelas apa yang TIDAK termasuk. Senarai ini lebih berguna daripada senarai apa yang termasuk.
- Tandatangan dokumen itu. Perubahan selepas ini normal — tetapi ia dibincang, bukan diandaikan.
4. Bayar sekali gus di hadapan
Membayar 100% di awal membuang satu-satunya pengaruh yang anda ada. Membayar 100% di akhir pula membuatkan vendor yang baik menolak kerja itu — dan itu munasabah.
Struktur yang adil
| Peringkat | Bahagian | Dibayar bila |
|---|---|---|
| Mula | 30% | Selepas skop ditandatangan |
| Reka bentuk siap | 20% | Selepas anda lulus semua skrin |
| Boleh dicuba | 30% | Selepas anda boleh guna sendiri |
| Serahan | 20% | Selepas kod, akaun dan dokumentasi diserahkan |
Peringkat terakhir itu penting. Ia memastikan penyerahan benar-benar berlaku, bukan dijanjikan.
5. Tiada rancangan untuk selepas serahan
Sistem bukan bangunan siap. Android dan iOS berubah setiap tahun. Pustaka keselamatan perlu dikemas kini. Peraturan store berubah. Sijil tamat tempoh.
Corak biasa: sistem berjalan baik selama setahun. Kemudian sesuatu berhenti berfungsi pada hari Jumaat, dan tiada siapa yang bertanggungjawab.
Cara elak
- Tanya sebelum menandatangan: "Berapa lama pepijat dibaiki tanpa caj selepas serahan?" Jawapan yang munasabah: 30 hingga 90 hari.
- Tanya "Apa yang berlaku selepas itu?" Sama ada pelan penyelenggaraan bulanan, atau kadar sejam yang dinyatakan awal.
- Minta dokumentasi penyerahan: di mana ia dihoskan, bagaimana ia digunakan semula, di mana sandaran, siapa perlu dihubungi untuk domain.
- Sahkan sandaran benar-benar berfungsi. Sandaran yang tidak pernah dipulihkan bukan sandaran — ia andaian. Minta mereka tunjukkan pemulihan sekali di hadapan anda.
Senarai semak sebelum tandatangan
- Kod sumber menjadi milik saya, bertulis
- Domain, hosting, akaun store dan pembayaran atas nama saya
- Senarai skrin dan kebenaran akses ditulis dan dipersetujui
- Senarai perkara yang TIDAK termasuk ditulis
- Bayaran berperingkat, peringkat akhir terikat pada penyerahan
- Tempoh jaminan pepijat dinyatakan dalam hari
- Kos penyelenggaraan selepas jaminan diketahui awal
- Pemulihan sandaran ditunjukkan sekali sebelum pembayaran akhir
Lapan baris ini menyelesaikan hampir setiap pertikaian yang pernah kami lihat. Ia mengambil masa sejam untuk dipersetujui, dan menjimatkan berbulan.