Mengapa Proyek Software Sering Meleset Sejak Hari Pertama
Bayangkan Anda mengirim pesan yang sama ke tiga vendor: "Kami butuh aplikasi untuk mengelola pesanan." Penawaran yang kembali bisa berbeda berkali lipat, dan ketiganya sama-sama masuk akal. Vendor pertama membayangkan spreadsheet online sederhana, vendor kedua membayangkan sistem lengkap dengan aplikasi mobile, dan vendor ketiga menebak di tengah-tengah. Anda tidak sedang membandingkan harga, melainkan membandingkan tiga tafsiran berbeda atas satu kalimat.
Di post Mengapa Proyek Otomasi Gagal, kami menyebut scope yang membengkak tanpa spesifikasi sebagai pembunuh nomor satu. Post ini adalah jawaban praktisnya: cara menulis spesifikasi ringkas sebelum satu baris kode pun ditulis. Yang sering kami temui, dokumen dua sampai lima halaman yang ditulis dengan benar jauh lebih berguna daripada dokumen lima puluh halaman yang tidak pernah dibaca ulang.
Spesifikasi Bukan Dokumen Tebal
Banyak pemilik bisnis menunda menulis spesifikasi karena membayangkan dokumen teknis yang rumit. Padahal tujuannya sederhana: membuat semua pihak punya gambaran yang sama tentang apa yang dibangun, untuk siapa, dan kapan disebut selesai.
Standar internasional rekayasa kebutuhan, ISO/IEC/IEEE 29148:2018, memang mendefinisikan proses dan ciri kebutuhan yang baik secara mendetail. Anda tidak perlu mengikutinya kata per kata untuk proyek bisnis berskala kecil–menengah. Namun ada satu prinsip yang sangat berguna dari dunia rekayasa sistem: kebutuhan menyatakan apa yang harus dilakukan sistem, bukan bagaimana cara membangunnya (SEBoK, System Requirements Definition). Pilihan framework, database, dan arsitektur adalah tugas tim teknis. Tugas Anda adalah menjelaskan masalah dan hasil yang diharapkan.
Atlassian juga mencatat beberapa pola yang perlu dihindari dalam panduan dokumen kebutuhan produk mereka: seluruh proyek dirinci habis sebelum engineering dimulai, kebutuhan ditulis tanpa melibatkan tim, dan dokumen tidak pernah diperbarui setelah disetujui. Spesifikasi yang baik cukup jelas untuk mulai, dan cukup ringan untuk diubah.
Template Spesifikasi Ringkas
Berikut enam bagian yang kami sarankan. Bagian ini diadaptasi dari struktur yang umum dipakai, termasuk template Atlassian (tujuan, asumsi, user story, pertanyaan terbuka, dan "yang tidak kami kerjakan").
1. Tujuan dan masalah bisnis
Tulis dalam satu atau dua paragraf: masalah apa yang terjadi hari ini, siapa yang terdampak, dan mengapa harus diselesaikan sekarang. Hindari menulis solusi di bagian ini.
Contoh: "Admin gudang mencatat pesanan dari WhatsApp ke spreadsheet secara manual. Pesanan sering tertukar dan laporan stok baru tersedia di akhir minggu."
2. Pengguna dan peran
Daftar siapa saja yang memakai sistem dan apa wewenangnya. Admin, kasir, manajer, dan pelanggan punya kebutuhan yang berbeda. Daftar ini juga menjadi dasar desain hak akses.
Solusi: buat tabel sederhana berisi peran, jumlah perkiraan pengguna, dan tindakan utama yang mereka lakukan.
3. Alur utama dalam bentuk user story
Service Manual GOV.UK menyarankan setiap user story memuat tiga hal: siapa penggunanya, apa yang ia butuhkan, dan mengapa ia membutuhkannya. Formatnya:
Sebagai [pengguna], saya ingin [melakukan sesuatu], agar [tujuan tercapai].
Menurut panduan yang sama, bagian terpenting adalah tujuannya. Jika Anda kesulitan menulis "agar …", pertimbangkan ulang apakah fitur itu memang dibutuhkan.
Lengkapi setiap story dengan acceptance criteria (kriteria penerimaan) yang diawali "selesai jika …". Contoh:
- Selesai jika admin bisa membuat pesanan baru dalam satu layar.
- Selesai jika stok berkurang otomatis saat pesanan dikonfirmasi.
- Selesai jika manajer bisa mengunduh laporan harian dalam format Excel.
Kriteria ini adalah alat paling ampuh untuk menghindari debat "menurut saya sudah selesai" di akhir proyek.
4. Scope fase 1 dan hal di luar scope
Pisahkan dengan tegas apa yang dikerjakan di fase pertama dan apa yang ditunda. Bagian "di luar scope" sama pentingnya: menulis "aplikasi mobile tidak termasuk fase 1" mencegah asumsi diam-diam yang baru muncul saat demo.
Solusi: gunakan tiga kolom: wajib di fase 1, bisa menyusul, dan tidak dikerjakan. Jika semua masuk kolom pertama, scope belum benar-benar diprioritaskan.
5. Data, integrasi, dan batasan
Catat sistem yang sudah ada dan harus terhubung (aplikasi akuntansi, payment gateway, WhatsApp), data yang harus dipindahkan, serta batasan non-fungsional: perkiraan jumlah pengguna, jam operasional, kebutuhan keamanan, dan regulasi seperti UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi jika sistem menyimpan data pelanggan. Untuk integrasi, bacaan lanjutan kami ada di 5 Kesalahan Integrasi API dan panduan WhatsApp Business API.
6. Indikator keberhasilan dan pertanyaan terbuka
Tentukan bagaimana Anda tahu proyek ini berhasil, misalnya waktu input pesanan, jumlah kesalahan pencatatan, atau kecepatan laporan. Ukur kondisi saat ini dulu, karena tanpa angka awal tidak ada pembanding. Kerangka yang lebih lengkap ada di post Mengukur ROI Integrasi AI.
Tutup dengan daftar pertanyaan terbuka: hal yang belum Anda ketahui. Dalam rekayasa sistem, nilai yang belum pasti biasa ditandai "TBD" (to be determined) dan dilacak sampai terjawab. Menuliskan ketidakpastian secara jujur jauh lebih baik daripada menebak.
Cara Memakai Spesifikasi untuk Meminta Penawaran yang Adil
Spesifikasi yang sama, dikirim ke semua vendor, membuat penawaran bisa dibandingkan secara apel-dengan-apel.
- Kirim dokumen yang sama ke setiap vendor, termasuk bagian di luar scope dan pertanyaan terbuka.
- Minta rincian per fitur atau per story, bukan satu angka total. Perbedaan besar pada satu fitur biasanya menandakan tafsiran yang berbeda.
- Perhatikan pertanyaan balik vendor. Vendor yang bertanya tentang alur, data, dan pengecualian biasanya membaca dokumen Anda dengan serius.
- Minta asumsi tertulis di dalam penawaran. Asumsi yang berbeda adalah sumber utama sengketa di tengah proyek.
- Sepakati proses perubahan. Scope pasti berubah; yang penting adalah cara mencatat, menilai biaya, dan menyetujui perubahan itu.
Jika Anda masih menimbang antara membangun sistem sendiri atau berlangganan SaaS, spesifikasi ini juga menjadi bahan utama untuk kerangka membangun vs. membeli.
Kesalahan yang Sering Kami Temui
1. Menulis solusi, bukan masalah
"Kami butuh dashboard dengan 12 grafik" adalah solusi. Masalahnya mungkin "manajer tidak tahu stok kritis sampai terlambat", yang bisa diselesaikan dengan satu notifikasi.
Solusi: untuk setiap fitur, tanyakan "masalah apa yang diselesaikan ini?" dan tulis jawabannya.
2. Tidak melibatkan pengguna sehari-hari
Spesifikasi yang hanya ditulis oleh pimpinan sering melewatkan pengecualian yang dihadapi staf setiap hari: retur, pesanan sebagian, atau pembayaran yang dicicil.
Solusi: wawancarai minimal satu orang dari setiap peran sebelum dokumen dianggap final.
3. Spesifikasi dibekukan
Atlassian menyebut dokumen yang tidak pernah diperbarui sebagai salah satu tantangan utama. Spesifikasi adalah dokumen hidup.
Solusi: tetapkan satu pemilik dokumen dan catat setiap perubahan beserta tanggal dan alasannya.
Checklist Sebelum Menghubungi Vendor
- Tujuan bisnis tertulis tanpa menyebut teknologi.
- Semua peran pengguna terdaftar.
- Alur utama tertulis sebagai user story dengan kriteria "selesai jika …".
- Scope fase 1 dan hal di luar scope dipisahkan.
- Sistem yang harus terhubung dan data yang harus dipindahkan tercatat.
- Indikator keberhasilan dan kondisi awalnya diukur.
- Pertanyaan terbuka didaftar, bukan ditebak.
Pendekatan AY Labs
Kami tidak memulai proyek dengan menulis kode, tetapi dengan menyusun spesifikasi bersama Anda. Jika Anda datang dengan brief singkat, kami membantu mengubahnya menjadi user story, kriteria penerimaan, dan batas scope fase 1 yang disepakati sebelum penawaran final. Jika Anda sudah punya dokumen, kami membacanya dengan kritis dan mengembalikan daftar asumsi serta pertanyaan terbuka secara tertulis. Dengan begitu, angka di penawaran kami bisa ditelusuri ke setiap fitur, dan perubahan di tengah jalan punya proses yang jelas. Jika Anda sedang menyiapkan proyek software, kami siap membantu merapikan spesifikasinya terlebih dahulu.
