Sebelum meminta penawaran jasa website, aplikasi, atau sistem, siapkan tujuan, pengguna, fungsi prioritas, kondisi saat ini, serta gambaran waktu dan anggaran. Anda tidak harus mempunyai dokumen teknis lengkap. Catatan singkat tentang pekerjaan yang ingin dipermudah sudah bisa menjadi bahan pembahasan awal.
Pertanyaan tentang biaya biasanya muncul lebih dahulu. Itu wajar, tetapi jawaban yang berguna memerlukan gambaran pekerjaan. Website untuk memperkenalkan jasa berbeda dari aplikasi yang menyimpan transaksi, meskipun keduanya terlihat sederhana pada layar.
Saya membantu membahas kebutuhan tersebut sebelum menyusun penawaran. Dengan informasi yang lebih jelas, Anda dapat melihat apa yang dikerjakan, bagian yang belum termasuk, dan pilihan yang masih perlu diputuskan. Panduan ini membantu Anda menyiapkannya tanpa harus menjadi orang teknis.
Mulai dengan enam informasi inti
Untuk kontak pertama, cukup sampaikan hal yang sudah Anda ketahui:
- Jenis usaha dan masalah yang paling ingin diselesaikan.
- Orang yang akan menggunakan website atau aplikasi tersebut.
- Fungsi yang harus tersedia agar kebutuhan utama terpenuhi.
- Website, sistem, materi, atau pencatatan yang sudah digunakan.
- Target penggunaan beserta alasan waktunya.
- Kisaran anggaran, jika sudah ditentukan.
Jika belum tahu jawabannya, jelaskan bagian yang masih membingungkan. Misalnya, Anda sudah mengetahui proses pemesanan terlalu banyak berpindah percakapan, tetapi belum tahu apakah solusinya formulir, aplikasi pelanggan, atau sistem internal.
Tidak perlu menunggu presentasi yang rapi. Ringkasan melalui jalur kontak resmi dapat menjadi awal percakapan. Rincian berikut membantu ketika kebutuhan mulai dibahas lebih jauh.
Jelaskan kegunaannya sebelum memilih nama produknya
Istilah website, aplikasi, dan sistem sering saling beririsan. Aplikasi dapat dibuka melalui browser, sedangkan website publik dapat terhubung dengan sistem internal. Karena itu, jelaskan tugasnya sebelum mengunci bentuk solusi.
| Kebutuhan awal | Contoh tujuan | Informasi yang perlu diperjelas |
|---|---|---|
| Website bisnis | Menjelaskan layanan dan menerima pertanyaan | Materi, bahasa, jalur kontak, serta bagian yang perlu diedit |
| Aplikasi untuk pengguna | Memesan layanan atau memantau permintaan | Perangkat, akun, alur penggunaan, notifikasi, dan kebutuhan koneksi |
| Sistem internal | Mencatat pekerjaan dan mengatur persetujuan | Peran staf, data, tahapan proses, laporan, dan hubungan dengan sistem lain |
Tabel ini adalah titik awal pembahasan, bukan batas kategori. Katalog dengan tombol kontak dan katalog dengan pembayaran serta pembaruan stok mempunyai pekerjaan berbeda. Jika kebutuhan utamanya masih berupa website publik, panduan memilih landing page, company profile, atau toko online dapat membantu mempersempit pilihan.
Untuk aplikasi, sebutkan apakah pengguna akan mengaksesnya melalui browser atau aplikasi seluler. Kebutuhan penggunaan tanpa koneksi, kamera, atau perangkat tertentu juga perlu dibahas. Jangan menganggap semua cara akses termasuk hanya karena penawaran menyebut aplikasi.
Ceritakan satu proses dari awal sampai selesai
Daftar fitur menjadi lebih mudah dipahami jika disertai alur kerja. Jelaskan siapa yang memulai, informasi apa yang masuk, siapa yang menindaklanjuti, dan hasil yang dibutuhkan.
GOV.UK menjelaskan kebutuhan pengguna melalui pelaku, tugas, dan tujuannya. Untuk pembahasan proyek, pola ini membantu mengubah nama fitur menjadi pekerjaan yang dapat dijelaskan.
Sebagai ilustrasi, permintaan saya ingin aplikasi booking masih menyisakan banyak kemungkinan. Penjelasan yang lebih berguna adalah: pelanggan mengirim permintaan jadwal, admin memeriksa ketersediaan teknisi, lalu pelanggan menerima konfirmasi. Jadwal belum dianggap pasti sebelum admin menyetujui.
Rincian terakhir memengaruhi rancangan. Sistem konfirmasi manual berbeda dari pemesanan otomatis yang langsung mengunci slot. Keduanya bisa sesuai, bergantung pada proses usaha Anda.
Sertakan pengecualian yang sering terjadi, misalnya pelanggan mengganti jadwal atau petugas tidak tersedia. Tidak perlu mencatat semua kemungkinan pada hari pertama. Mulailah dari keadaan yang paling sering menghambat pekerjaan.
Tentukan pengguna, akses, dan kondisi pemakaian
Siapa yang memakai sistem akan memengaruhi fungsi dan pemeriksaannya. Pemilik usaha, admin, staf lapangan, dan pelanggan belum tentu boleh melihat atau mengubah informasi yang sama.
Panduan otorisasi OWASP menganjurkan pemetaan pengguna, sumber daya, dan tindakan yang diizinkan sejak perancangan. Akses sebaiknya mengikuti tugas yang diperlukan. Dalam brief, terangkan misalnya bahwa petugas hanya boleh melihat pekerjaan yang ditugaskan kepadanya.
Sampaikan perkiraan jumlah pengguna, transaksi, dan data jika tersedia. Bedakan pengguna terdaftar dengan orang yang aktif bersamaan. Jika angkanya belum diukur, tulis sebagai perkiraan agar tidak dianggap kapasitas yang sudah terbukti.
Kondisi penggunaan juga penting. Staf yang bekerja dari ponsel dengan koneksi tidak stabil mempunyai kebutuhan berbeda dari admin kantor yang memakai komputer. Sebutkan bahasa, perangkat, serta kebutuhan aksesibilitas pengguna yang diketahui.
W3C menempatkan tujuan, lingkup, tanggung jawab, dan sumber daya dalam perencanaan aksesibilitas. Jika ada standar atau pemeriksaan khusus yang perlu dipenuhi, bahas sejak awal agar pekerjaannya dapat diperhitungkan. Tampilan responsif saja belum menjelaskan seluruh kebutuhan tersebut.
Pisahkan kebutuhan awal dari pengembangan berikutnya
Penawaran lebih mudah dinilai ketika fungsi dibagi berdasarkan kepentingannya. Tentukan bagian yang harus tersedia saat pertama digunakan, bagian yang berguna tetapi dapat menyusul, dan gagasan yang masih perlu dipelajari.
Pada ilustrasi pemesanan tadi, pencatatan permintaan dan konfirmasi admin mungkin sudah cukup untuk tahap awal. Pembayaran otomatis atau pengingat terjadwal dapat dibahas kemudian bila memang dibutuhkan. Pembagian ini tidak berarti fitur lanjutan pasti mudah ditambahkan; pengaruhnya terhadap rancangan tetap perlu dinilai.
Jelaskan pula rencana pertumbuhan yang sudah diketahui, seperti cabang baru, bahasa tambahan, atau layanan yang akan diluncurkan. Informasi itu membantu mempertimbangkan perubahan tanpa memasukkan seluruh gagasan ke pekerjaan pertama.
Saya dapat membantu membahas prioritas tersebut agar penawaran menjawab kebutuhan yang sedang dihadapi. Anda tetap dapat membandingkan pilihan berdasarkan pekerjaan yang jelas, termasuk konsekuensi ketika suatu fungsi ditunda.
Siapkan materi dan referensi yang relevan
Untuk website bisnis, inventaris awal dapat mencakup daftar layanan, profil usaha, logo, foto, informasi kontak, dan bahasa yang diperlukan. Sampaikan materi mana yang sudah siap, perlu diperbaiki, atau belum tersedia.
Bedakan pembuatan tampilan dengan pekerjaan menulis, menerjemahkan, memotret, atau memasukkan banyak produk. Jangan menganggap seluruh pekerjaan konten termasuk dalam biaya pembangunan. Isi akhir dan hak penggunaannya perlu jelas sebelum dipublikasikan.
Konten yang saya sediakan untuk proyek adalah materi sementara untuk pratinjau. Anda wajib menggantinya sebelum penggunaan publik atau komersial, kecuali lingkup tertulis secara tegas mencakup konten final untuk penggunaan tersebut. Hak penggunaan dan ketentuan lisensinya tetap berlaku.
Referensi desain akan lebih berguna jika disertai alasan. Jelaskan bahwa Anda menyukai susunan layanan, cara memilih produk, atau keterbacaan halaman di ponsel. Tautan referensi membantu pembahasan arah, tetapi tidak memberikan izin menyalin materi, kode, atau identitas pihak lain.
Untuk sistem internal, contoh formulir kosong atau laporan dengan data fiktif dapat membantu menjelaskan informasi yang dibutuhkan. Jangan sertakan kata sandi, kunci API, atau catatan pelanggan yang sebenarnya pada kontak awal.
Catat sistem lama, integrasi, dan data yang perlu dipindahkan
Jika proyek melanjutkan sistem yang sudah ada, sebutkan alamat website, layanan yang digunakan, akses yang tersedia, dan kendala utamanya. Jelaskan juga apakah pengguna masih harus bekerja pada sistem lama selama perpindahan.
Kata integrasi perlu diterjemahkan menjadi aliran informasi. Data apa yang dikirim, dari mana asalnya, ke mana tujuannya, dan kapan harus diperbarui? Mengirim permintaan ke satu layanan berbeda dari menyelaraskan perubahan antara dua sistem.
Catat dokumentasi resmi atau fasilitas integrasi yang diketahui. Ketersediaan akses, batas pemakaian, biaya layanan, dan izin penyedia perlu diperiksa sebelum kelayakan dijanjikan. Jangan langsung mengirim kredensial untuk membuktikan bahwa Anda memiliki akun.
Untuk migrasi, sebutkan jenis data, perkiraan jumlah, format yang tersedia, dan bagian yang harus tetap dapat digunakan. Memindahkan daftar produk tidak selalu sama dengan memindahkan riwayat transaksi beserta lampirannya.
Panduan GOV.UK menyarankan perencanaan biaya dan waktu untuk berpindah dari penyedia cloud. Jika proyek bergantung pada platform tertentu, rencana biaya dan kelanjutan layanan perlu mempertimbangkan batas tersebut. Website custom juga dapat mempunyai ketergantungan pada layanan lain.
Kode sumber tidak otomatis termasuk dalam layanan saya dan tidak selalu tersedia. Akses panel, domain, data, lisensi, dan kode merupakan hal berbeda. Jika ada kebutuhan penyerahan atau perpindahan tertentu, sampaikan sebelum menyetujui penawaran. Pembahasan lebih lengkap tersedia pada panduan akses website dan ketergantungan penyedia.
Sampaikan anggaran dan alasan target waktunya
Kisaran anggaran membantu membahas pilihan yang layak. Angka tersebut bukan kewajiban untuk dihabiskan seluruhnya. Jika anggaran belum ditentukan, sampaikan prioritas dan batas yang sudah diketahui agar pilihan pekerjaan dapat dibahas lebih dahulu.
Pisahkan biaya pembangunan dari biaya berulang. Domain, hosting, langganan layanan, lisensi, pemakaian API, serta pengelolaan dapat mempunyai tagihan sendiri sesuai rancangan. Penggunaan AI untuk membantu pembuatan tidak otomatis berarti website membutuhkan API AI berbayar saat dijalankan.
Untuk waktu, jelaskan pemicunya: pembukaan cabang, pergantian proses kerja, atau kebutuhan mengganti sistem lama. Bedakan tanggal yang diharapkan dengan batas waktu yang memang tidak dapat digeser.
Jadwal juga bergantung pada materi, akses, keputusan, pengujian, serta layanan pihak ketiga yang diperlukan. Tanggal target dari klien belum menjadi janji penyelesaian sebelum kelayakan dan lingkupnya dibahas. Menyampaikan batas waktu sejak awal membantu menilai apakah pekerjaan perlu dibagi menjadi beberapa tahap.
Jelaskan hasil yang akan Anda periksa
Permintaan seperti mudah digunakan atau fiturnya lengkap masih perlu diterjemahkan. Tentukan tugas yang harus dapat dilakukan dan kondisi ketika tugas tersebut dianggap berhasil.
GOV.UK menggunakan kriteria penerimaan untuk memeriksa apakah kebutuhan pengguna sudah terpenuhi. Dalam ilustrasi pemesanan, pemeriksaan dapat mencakup permintaan yang tercatat, perubahan status oleh admin yang berwenang, dan konfirmasi yang sesuai dengan keputusan admin.
Anda tidak harus menulis skenario uji teknis sendiri. Ceritakan hasil yang Anda harapkan dan kesalahan yang paling mengganggu jika terjadi. Dari sana, pemeriksaan yang diperlukan dapat dibahas dalam lingkup proyek.
Jika ada perhitungan, lampirkan contoh input dan hasil yang diharapkan dengan data fiktif. Jika ada laporan, tunjukkan informasi yang diperlukan untuk mengambil keputusan. Ini lebih membantu daripada hanya menuliskan nama fitur dashboard atau laporan lengkap.
Di mana website custom dan bantuan engineer memberi nilai?
Brief yang jelas membantu menentukan apakah alat siap pakai sudah memadai atau diperlukan penyesuaian. Nilai website custom muncul ketika susunan informasi dan fungsi perlu mengikuti proses bisnis yang lebih spesifik.
Pada usaha servis, misalnya, permintaan dari pelanggan mungkin harus diteruskan ke cabang yang tepat sebelum admin mengatur petugas. Saya membantu membahas alur tersebut, menentukan batas pekerjaan, dan menilai bagian yang perlu disesuaikan. Jika fasilitas yang sudah Anda gunakan mencukupi, pembangunan baru tidak harus menjadi pilihan pertama.
AI dapat membantu menyusun ide atau membuat prototipe. Namun, prototipe formulir belum menjawab siapa yang boleh melihat permintaan, bagaimana perubahan status ditangani, atau apakah prosesnya cocok dengan pekerjaan staf. Sebagai web engineer dan technical lead, saya membantu menerjemahkan kebutuhan itu menjadi keputusan dan pemeriksaan sesuai lingkup proyek.
Anda dapat membahasnya langsung dengan saya tanpa harus memilih teknologi lebih dahulu. Untuk website publik, fondasi SEO, performa, dan keamanan dapat dikoordinasikan dengan desain sesuai penawaran; pekerjaan tersebut tidak menjamin peringkat, penjualan, atau sistem bebas gangguan. Perbandingan pendekatan tersedia pada website custom atau AI website builder.
Gunakan sepuluh pertanyaan ini sebagai brief sederhana
Salin pertanyaan berikut ke catatan Anda, lalu jawab yang sudah diketahui. Kalimat biasa sudah cukup; bagian yang belum jelas dapat menjadi bahan diskusi.
- Usaha atau organisasi apa yang akan menggunakan hasil proyek ini?
- Masalah apa yang ingin diselesaikan, dan bagaimana pekerjaan dilakukan sekarang?
- Siapa penggunanya, dan apa yang boleh dilakukan masing-masing?
- Alur atau fungsi apa yang wajib tersedia pada tahap pertama?
- Hasil apa yang ingin diperiksa untuk memastikan fungsi tersebut sesuai kebutuhan?
- Materi, data contoh, dan sistem apa yang sudah tersedia?
- Apakah ada integrasi, migrasi, atau kondisi penggunaan khusus?
- Referensi apa yang disukai, dan bagian mana yang relevan?
- Kapan hasilnya dibutuhkan, mengapa, dan berapa kisaran anggarannya jika sudah ada?
- Siapa yang menyatukan keputusan proyek dan mengelola hasilnya setelah digunakan?
Jangan mengubah catatan ini menjadi beban administrasi. Jika baru dapat menjelaskan masalah dan tujuan, mulai dari sana. Hindari mengirim data rahasia; kebutuhan penanganan informasi sensitif dapat dibicarakan sebelum materi tersebut dibagikan.
Setelah kebutuhan dikirim, apa yang perlu diperjelas?
Informasi awal menjadi bahan untuk menanyakan bagian yang belum jelas dan menentukan kemungkinan pekerjaan. Jika kondisi sistem lama memerlukan pemeriksaan lebih lanjut, lingkup dan biayanya, bila ada, dibahas sebelum pekerjaan tersebut dilakukan.
Sebelum menyetujui penawaran, cocokkan hasil yang akan diterima, pekerjaan konten, integrasi, jumlah atau batas revisi, cara pemeriksaan, pembayaran, serta perkiraan jadwal. Periksa juga biaya rutin, hak penggunaan, akses yang diserahkan, dan bantuan setelah peluncuran.
Tunjuk satu narahubung untuk menyatukan keputusan. Masukan dari beberapa orang tetap dapat dikumpulkan, tetapi instruksi akhirnya perlu konsisten. Jika kebutuhan berubah, pengaruhnya terhadap biaya dan jadwal disepakati sebelum pekerjaan tambahan dimulai.
Brief membantu pembahasan; brief saja belum menjadi pemesanan atau kesepakatan seluruh layanan. Pekerjaan mengikuti penawaran dan ketentuan layanan yang disetujui. Anda tidak perlu menuntaskan semua rincian sendiri untuk memulai percakapan, tetapi keputusan penting perlu jelas sebelum pengerjaan.
Pertanyaan yang sering diajukan
Apa yang perlu disiapkan sebelum meminta penawaran website, aplikasi, atau sistem?
Mulai dari gambaran usaha, masalah yang ingin diselesaikan, pengguna, fungsi prioritas, kondisi materi atau sistem saat ini, serta target waktu dan kisaran anggaran jika sudah ada. Informasi yang belum diketahui dapat dibahas; dokumen teknis lengkap bukan syarat untuk menghubungi saya.
Bisakah meminta penawaran jika belum memahami teknologi?
Bisa. Jelaskan pekerjaan yang ingin dipermudah dengan bahasa sehari-hari. Contoh alur, formulir kosong, atau tampilan tanpa data rahasia membantu pembahasan. Pilihan teknologi dan kelayakan kebutuhan dibahas setelah tujuannya dipahami.
Apakah jumlah halaman cukup untuk menentukan biaya website?
Belum. Jenis isi, fungsi, bahasa, fasilitas edit, integrasi, dan kesiapan materi ikut menentukan pekerjaan. Dua website dengan jumlah halaman sama dapat memerlukan lingkup yang berbeda.
Apakah kisaran anggaran berarti seluruh anggaran harus digunakan?
Tidak. Kisaran anggaran menjadi batas untuk membahas pilihan dan prioritas. Harga yang ditawarkan mengikuti lingkup pekerjaan serta layanan yang disepakati, bukan kewajiban menghabiskan seluruh anggaran Anda.
Apakah saya harus mengirim kata sandi saat meminta penawaran?
Tidak untuk pembahasan awal. Kirim gambaran kebutuhan dan contoh yang tidak memuat kredensial atau data pribadi. Jika akses diperlukan untuk pemeriksaan lanjutan, izin, lingkup, dan cara pemberiannya perlu disepakati terlebih dahulu.
Apakah penawaran otomatis mencakup kode sumber dan pemeliharaan?
Tidak. Kode sumber, akses pengelolaan, pemeliharaan, migrasi, pelatihan, dan dukungan memiliki lingkup tersendiri. Penyerahan kode sumber tidak otomatis termasuk dan tidak selalu tersedia. Periksa hasil serta hak penggunaan yang tercantum dalam penawaran.
