Gambaran besar dulu, baru detail
Bayangkan kamu disuruh bangun rumah, tapi belum tahu siapa yang bakal tinggal di situ. Berapa kamar yang dibutuhkan? Ada anak kecil yang perlu ruang bermain, atau malah rumah buat kakek-nenek yang butuh kamar mandi tanpa tangga? Kalau kamu asal bangun tanpa tanya dulu, hasilnya bisa berantakan, kamar kurang, atau malah kebanyakan ruang kosong yang percuma.
Membangun jaringan komputer persis seperti itu. Sebelum menggelar kabel, beli router, atau mikir topologi, kamu wajib tahu dulu siapa yang bakal pakai jaringan ini dan buat apa. Proses tanya-tanya ini namanya site survey atau analisis kebutuhan pengguna (User Requirement Analysis, disingkat URA). Intinya sederhana: ngobrol dulu sama calon pengguna, baru gambar desainnya.
Ada lima hal wajib yang harus digali waktu ngobrol itu:
- Jumlah host: berapa banyak perangkat (komputer, laptop, printer, HP) yang bakal nyambung ke jaringan. Ini seperti tanya “rumahnya buat berapa orang” tadi.
- Jenis layanan: dipakai buat apa saja. Sekadar browsing dan kirim email, atau ada video call dan upload file besar tiap hari?
- Kebutuhan bandwidth: seberapa besar “pipa data” yang dibutuhkan. Semakin berat aktivitasnya, semakin besar pipa yang harus disiapkan.
- Tingkat ketersediaan (uptime): seberapa sering jaringan ini boleh mati. Warnet buat main santai beda jauh kebutuhannya dengan toko online yang buka 24 jam.
- Kebutuhan keamanan: data apa yang harus dijaga, dan dari siapa dijaganya.
Lewatkan salah satu dari lima ini, dan jaringan yang kamu bangun bisa saja jalan, tapi tidak sesuai kebutuhan orang yang pakai.
Contoh nyata biar kebayang
Ada kantor dinas pendidikan di sebuah kota yang punya 18 komputer, tersebar di 8 bagian: Perencanaan, Tata Usaha, Pengawas, Keuangan, Dikmen, Dikdas, Olahraga, dan Ketenagaan. Total bandwidth internet mereka cuma 1 Mbps, dibagi rata ke semua komputer tanpa aturan.
Masalahnya ketahuan belakangan. Bagian Perencanaan punya tugas wajib: upload dan validasi data siswa secara online ke provinsi, tiap bulan, dan itu tidak boleh telat. Tapi begitu bagian Tata Usaha atau Dikmen lagi download file besar, koneksi Perencanaan ikut lemot. Upload data pentingnya jadi tersendat, padahal itu tugas dengan tenggat waktu.
Solusinya baru ketemu setelah dilakukan analisis kebutuhan yang benar: tiap bagian dicek dulu, aktivitas internetnya ngapain saja. Bagian Perencanaan yang tugasnya berat dan mendesak dikasih jatah bandwidth lebih besar (128–256 Kbps), sementara bagian Pengawas yang cuma sesekali browsing dan download data ringan cukup dikasih 32–64 Kbps. Jaringan yang sama, cuma dibagi ulang berdasarkan kebutuhan nyata hasilnya, semua bagian bisa kerja tanpa saling rebutan bandwidth.
Ini contoh kenapa lima parameter tadi bukan basa-basi. Kalau dari awal ditanya “bagian mana yang kerjanya punya tenggat waktu ketat”, masalah lemotnya Perencanaan bisa dicegah dari awal, bukan diperbaiki belakangan.
Satu detail kecil yang juga lahir dari analisis kebutuhan: karena total perangkat cuma belasan (kurang dari 254 host), kantor itu cukup pakai IP kelas C. Kalau perangkatnya ribuan, baru perlu pertimbangkan kelas B. Jumlah host yang kamu gali di awal langsung menentukan pilihan teknis di belakang.
Skenario latihan: kamu jadi konsultan jaringan
Sekarang giliran kamu praktik. Kamu berperan sebagai Network Consultant, dan guru atau temanmu jadi “klien” dari organisasi rekaan, bisa sekolah, kantor, atau usaha kecil.
Begini alurnya:
- Siapkan dulu form wawancara. Isinya lima parameter di atas: jumlah host, jenis layanan, bandwidth, uptime, dan keamanan. Bikin pertanyaan turunan untuk masing-masing, jangan cuma satu baris.
- Tentukan dulu profil klien simulasinya. Organisasi apa, ada berapa divisi, bergerak di bidang apa. Ini penting supaya wawancara nanti tidak ngambang.
- Lakukan wawancara 20 menit. Catat semua jawaban klien detail, termasuk hal-hal yang menurut mereka penting meski kelihatannya di luar lima parameter tadi. Kadang justru dari situ muncul kebutuhan yang tidak kamu duga.
- Olah hasilnya selama 45 menit. Pisahkan mana jawaban yang sudah jelas dan mana yang masih perlu ditanyakan ulang. Wajar kalau ternyata ada yang bolong, itu tandanya proses wawancaramu jalan dengan benar.
- Susun draf dokumen User Requirement Analysis. Isinya enam bagian: nama organisasi, deskripsi bisnis, jumlah pengguna per divisi, layanan yang dibutuhkan, prioritas, dan batasan anggaran.
- Review draf itu bareng kelompok sebelum diserahkan. Cek lagi, ada yang kelewat atau tidak.
Dokumenmu dianggap selesai kalau enam komponen di atas lengkap semua, dan guru bisa lihat dari proses wawancaramu bahwa kamu memang menggali kebutuhan klien, bukan sekadar tanya seadanya lalu buru-buru selesai.
Jebakan yang sering kejadian
Kesalahan paling umum: siswa cuma nanya “komputernya ada berapa” terus berhenti di situ. Padahal itu baru satu dari lima parameter.
Dua hal yang paling sering kelewat adalah anggaran dan prioritas uptime. Klien yang bisnisnya jualan online butuh internet yang nyaris tidak boleh mati sedetik pun, beda jauh dengan klien yang cuma butuh internet buat browsing santai di sela kerja. Kalau kamu tidak tanya soal ini, desain jaringan yang kamu buat nanti bisa salah sasaran — terlalu mahal buat kebutuhan yang sebenarnya sederhana, atau sebaliknya, terlalu pas-pasan buat kebutuhan yang sebenarnya kritis.
Anggaran juga sering lupa dicatat. Padahal batasan anggaran itu yang nanti menentukan topologi apa yang realistis kamu pakai. Percuma merancang jaringan canggih kalau budgetnya cuma cukup buat satu switch kecil.
Kuis singkat
- Sebutkan lima parameter yang wajib digali sebelum merancang jaringan.
- Kenapa kantor dinas pendidikan di contoh tadi memilih IP kelas C, bukan kelas B?
- Kalau klienmu ternyata sebuah toko online yang buka 24 jam, parameter mana yang harus kamu gali paling dalam, dan kenapa?