Cek Kesiapan PRD Sebelum Diserahkan ke AI Coding Agent

PRD yang panjang belum tentu siap dibangun. Dokumen bisa terlihat rapi tetapi masih menyimpan pertanyaan yang hanya pemilik produk yang bisa jawab: siapa yang boleh melihat data, kapan pesanan dianggap selesai, apa yang terjadi ketika pembayaran gagal, atau fitur mana yang sengaja belum dibuat. Kalau lubang ini diserahkan ke AI coding agent, agent tetap akan memilih jawaban. Masalahnya, pilihan itu tidak selalu sama dengan keputusan bisnis Anda.

Skematik menyediakan pemeriksaan kesiapan PRD sebagai lapis deterministik sebelum Anda meneruskan dokumen ke agent. Pemeriksaan ini bukan memberi nilai gaya menulis. Ia mencari hal-hal objektif yang membuat implementasi rawan melenceng: pertanyaan terbuka, fitur tanpa acceptance criteria, arsitektur atau struktur folder yang belum jelas, jalur tugas yang tidak masuk akal, hingga aturan keamanan yang belum tercakup.

Bedakan PRD selesai ditulis dengan PRD siap dikerjakan

PRD selesai ditulis ketika semua bagian sudah terisi. PRD siap dikerjakan ketika seorang agent dapat mengambil satu tugas, mengetahui ketergantungannya, mengetahui perilaku yang dianggap benar, dan menguji hasilnya tanpa harus mengarang aturan baru. Perbedaan ini penting karena AI sangat cepat menghasilkan kode yang tampak meyakinkan. Biaya sebenarnya muncul saat Anda baru menemukan asumsi yang salah setelah banyak file sudah berubah.

• Tujuan produk dan pengguna utama sudah jelas.
• Fitur punya hasil yang bisa diamati, bukan hanya kata seperti “modern” atau “mudah dipakai”.
• Data, peran pengguna, integrasi, dan informasi rahasia punya batas yang jelas.
• Tugas dipecah berurutan sehingga agent tahu apa yang harus selesai lebih dulu.
• Ada alur uji utuh yang dapat dicoba pemilik sebelum aplikasi dibagikan.

Kesiapan bukan berarti semua keputusan harus sempurna. Kesiapan berarti keputusan yang belum ada terlihat jelas, sehingga tidak diam-diam dibuat oleh agent.

Mulai dari pertanyaan terbuka yang hanya Anda bisa jawab

Pertanyaan terbuka bukan kegagalan. Ia justru catatan jujur bahwa ada keputusan yang belum dibuat. Contohnya: apakah pelanggan boleh membatalkan pesanan setelah dibayar, siapa yang dapat menghapus data, atau apakah satu akun boleh punya beberapa cabang. Jangan menyamarkan pertanyaan ini sebagai kalimat kabur. Tulis eksplisit, jawab sebelum implementasi bagian terkait, atau jadikan fitur itu non-goal MVP.

Saat melihat temuan kesiapan, selesaikan yang berdampak pada jalur inti terlebih dahulu. Tidak semua temuan perlu ditutup dalam satu sesi. Jika aplikasi belum membutuhkan multi-user, jangan memaksa desain organisasi yang rumit. Namun bila aplikasi memang memproses uang, data pelanggan, atau peran berbeda, aturan akses tidak boleh dibiarkan menjadi tebakan.

Pastikan setiap fitur punya bukti bahwa ia selesai

Acceptance criteria adalah kontrak perilaku. Untuk fitur daftar pelanggan, bukan cukup menulis “bisa kelola pelanggan”. Tulis hasil yang dapat dilihat: nama wajib diisi, nomor duplikat ditolak dengan pesan jelas, data baru muncul di daftar, dan pengguna hanya melihat data miliknya. Dengan kriteria seperti ini, agent memiliki arah implementasi sekaligus bahan uji.

Hubungkan juga kriteria itu ke task. Jika satu task membangun form dan task lain menyimpan data, hubungan keduanya harus terlihat. Task graph di Skematik membantu menunjukkan tugas yang belum bisa dikerjakan karena fondasinya belum selesai. Ini mengurangi kebiasaan menyuruh agent membangun halaman cantik sebelum aturan data dan validasinya diputuskan.

Periksa batas teknis sebelum kode dibuat

Agent perlu tahu bukan hanya fitur, tetapi juga lingkungan tempat fitur hidup. Bila ada login, jelaskan model autentikasi dan peran. Bila ada database, pastikan tabel dan relasi mendukung perhitungan yang disebut fitur. Bila ada layanan luar seperti pembayaran atau WhatsApp, tulis nama integrasi serta variabel lingkungan yang dibutuhkan. Jangan menulis rahasia di PRD; cukup sebut nama konfigurasi dan tempat ia dipakai.

Gunakan pemeriksaan kesiapan sebagai percakapan sebelum coding, bukan sebagai birokrasi sesudahnya. Skematik dapat menyiapkan arahan perbaikan untuk celah yang bisa ditutup. Untuk keputusan bisnis yang hanya pemilik tahu, jawabannya tetap harus datang dari Anda. Kombinasi kedua hal itu membuat PRD menjadi sumber keputusan, bukan hanya dokumen presentasi.

Lakukan satu putaran cek sebelum handoff

1. Baca lagi alur pengguna dari awal sampai selesai dan tandai titik yang masih bertanya “lalu bagaimana?”.
2. Pastikan setiap fitur inti memiliki acceptance criteria dan minimal satu kasus gagal yang penting.
3. Lihat urutan task: fondasi data, aturan bisnis, antarmuka, lalu uji dan dokumentasi.
4. Tutup atau catat pertanyaan terbuka sebelum task terkait diberikan kepada agent.
5. Baru ekspor prompt atau dokumen ke agent, lalu review perubahan kecil satu per satu.