Jumlah revisi

Berapa kali jumlah revisi situs web pada umumnya?

Tidak ada standar umum industri untuk jumlah revisi. Berbeda di tiap vendor dan paket, dan makin banyak halaman atau makin rumit fiturnya, jumlah revisinya cenderung dibuat lebih longgar.

Yang lebih penting dari angkanya adalah ‘bagaimana 1 kali revisi dihitung’. Meski sama-sama 5 kali, jumlah yang benar-benar bisa diubah sangat berbeda antara vendor yang menghitung satu kumpulan masukan sebagai 1 kali dan vendor yang menghitung satu titik perbaikan sebagai 1 kali.

Cek juga apakah jumlah revisi hanya berlaku di tahap draf desain, atau sampai tahap tampilan jadi.

Saat memilih jumlah revisi, pertimbangkan juga berapa orang yang ikut memutuskan. Usaha yang memutuskan bersama mitra usaha atau keluarga mungkin butuh lebih banyak revisi untuk menyamakan pendapat, jadi pilih yang lebih longgar atau tentukan dulu cara mengumpulkan pendapat.

Apa bedanya revisi dan pekerjaan tambahan?

Revisi adalah memperbaiki di dalam cakupan yang sudah disepakati, sedangkan pekerjaan tambahan adalah membuat hal baru di luar cakupan. Pekerjaan tambahan biasanya memerlukan biaya atau penawaran harga terpisah meskipun jatah revisi masih tersisa.

Batasnya sering samar, jadi cara paling pasti adalah bertanya lebih dulu sebelum meminta: ‘Ini termasuk revisi atau tambahan?’

Contoh yang samar: jika restoran meminta ‘Tolong tambahkan foto di daftar menu’, bisa jadi itu revisi yang hanya mengganti tempat foto yang sudah ada, atau pekerjaan membuat kolom foto baru untuk tiap menu. Jika ditanyakan sebelum meminta, jumlah revisi dan biayanya bisa diketahui lebih dulu.

Menambah konten berformat sama ke kerangka yang sudah ada, seperti studio kerajinan yang meminta ‘Tolong perkenalkan satu kelas lagi’, ada vendor yang menganggapnya revisi dan ada yang menganggapnya tambahan. Tidak ada jawaban baku, jadi ikuti saja kriteria yang tertulis di kontrak.

Bagaimana cara menghemat jatah revisi?

Kunci menghemat jatah revisi adalah mengumpulkan masukan sekaligus dan menuntaskan keputusan besar di tahap awal.

Jika setiap menerima versi revisi Anda menambahkan sedikit masukan baru, revisi tidak akan selesai. Pada pengecekan kali ini, fokuslah apakah permintaan sebelumnya sudah diterapkan dengan benar, dan kumpulkan masukan baru yang muncul untuk kiriman berikutnya.

Permintaan revisi sebaiknya dikirim per layar. Jika dirangkum seperti ‘layar beranda 3 hal, layar menu 2 hal’, pembuat situs tidak melewatkannya dan Anda pun mudah mengecek penerapannya.

1. 01Tetapkan daftar dan urutan halaman dengan pasti di tahap wireframe.
2. 02Sebelum draf desain, kirim dulu materi asli seperti foto · daftar harga · teks perkenalan.
3. 03Setelah menerima draf, lihat selama sehari-dua hari dan kumpulkan masukan dalam satu daftar.
4. 04Pendapat keluarga · karyawan Anda rangkum menjadi satu versi final.
5. 05Sebelum mengirim, pisahkan ‘yang wajib diubah’ dan ‘yang sebaiknya ada’.
6. 06Saat menerima versi revisi, cocokkan dengan daftar apakah semua item yang diminta sudah diterapkan.

Kenapa makin akhir tahapnya makin sulit diperbaiki?

Karena makin ke belakang, pekerjaan menumpuk di atas keputusan tahap sebelumnya. Memindahkan satu kotak di wireframe, di tampilan jadi berubah menjadi menyesuaikan ulang tata letak ponsel · jarak · tombol yang terhubung.

Misalnya, jika studio kerajinan berkata ‘ingin menerima reservasi kelas juga’ tepat sebelum selesai, layar reservasi dan fitur notifikasi harus dibuat baru, sehingga itu menjadi pekerjaan tambahan, bukan revisi. Jika permintaan yang sama disampaikan di konsultasi pertama, fitur itu bisa dimasukkan secara alami di tahap penyusunan.

Karena itu, ‘fitur yang mungkin dibutuhkan nanti’ sebaiknya disampaikan di konsultasi pertama. Meski tidak langsung dibuat, strukturnya bisa disiapkan agar mudah ditambahkan nanti.

Apa yang perlu ditulis di kontrak soal revisi?

Ketentuan revisi yang hanya disepakati secara lisan mudah diingat berbeda, jadi sebaiknya dicatat dalam angka dan kriteria di kontrak atau penawaran harga. Kementerian Sains dan TIK Korea juga membuat dan memublikasikan kontrak standar untuk bidang perangkat lunak, yang bisa dijadikan acuan tentang apa yang ditulis di kontrak.

Selain angka, ada baiknya pengecualian juga ditulis. Misalnya jika ada kalimat ‘revisi yang hanya mengubah huruf seperti salah ketik · koreksi kontak tidak dihitung’, Anda bisa meminta revisi kecil tanpa ragu.

Jika bingung soal sisa jatah, tanyakan ke vendor sudah berapa kali terpakai. Jika setiap meminta revisi Anda menulis urutannya, seperti ‘revisi ke-2’, catatan kedua pihak tidak akan berbeda.

• Jumlah revisi (dalam angka)
• Kriteria menghitung 1 kali (satu kumpulan masukan, atau satu item)
• Sampai tahap mana berlaku (draf desain · tampilan jadi · setelah rilis)
• Bagaimana biaya ditentukan jika jatah terlampaui
• Lama waktu sampai versi revisi diterima
• Apakah perbaikan error dari pembuat situs terpisah dari jatah

Bagaimana jika ingin mengubah situs setelah dirilis?

Perubahan setelah rilis biasanya ditangani terpisah dari jatah revisi tahap pembuatan. Konten yang terus berubah selama operasional, seperti jam buka · harga · foto, sering diubah lewat kontrak pemeliharaan atau panel admin.

Untuk usaha yang menu musimannya sering berganti seperti kafe, sebaiknya tentukan sebelum pembuatan ‘siapa yang mengubah menu dan bagaimana caranya’. Paket yang dipilih berbeda tergantung apakah Anda butuh panel admin untuk mengubah sendiri, atau cukup dengan cara vendor mengubahkan saat diminta.

Untuk tempat yang rutin menyesuaikan harga perawatan seperti salon, hitung kira-kira berapa kali perubahan setelah rilis dibutuhkan per bulan. Tergantung frekuensinya, mengubah sendiri atau menyerahkan ke vendor yang lebih praktis bisa berbeda.

Beberapa minggu pertama setelah rilis biasanya muncul hal yang perlu diperbaiki sambil melihat respons pelanggan. Ada baiknya dicek lebih dulu apakah perubahan di masa ini dianggap bagian dari cakupan pembuatan, atau beralih ke layanan pemeliharaan.