Alur Review Bank Soal di Lesan: Draft, Diajukan, Disetujui — Kenapa Tidak Langsung Publish?

Saat institusi mulai mengisi bank soal di Lesan, pertanyaan yang cukup sering muncul dari admin baru: kenapa soal yang baru dibuat tidak bisa langsung dipakai di asesmen? Kenapa harus melalui status Draft, lalu Diajukan untuk Review, baru bisa Disetujui? Jawabannya sederhana: alur ini bukan birokrasi tambahan, melainkan cara memindahkan kontrol kualitas yang biasanya sudah dilakukan institusi secara manual — dicek kepala bidang akademik lewat email atau grup WhatsApp — menjadi proses yang terstruktur dan bisa dilacak.

Kenapa Tidak Bisa Langsung Publish?

Konten soal adalah bagian dari apa yang institusi jual ke orang tua dan siswa. Kualitas soal — apakah kunci jawabannya benar, apakah pembahasannya jelas, apakah tingkat kesulitannya sesuai — berkontribusi langsung ke reputasi institusi. Kalau setiap guru bisa langsung mempublikasikan soal begitu selesai ditulis, tidak ada lapisan pengecekan sebelum soal itu dilihat ratusan siswa dalam satu tryout. Ini juga berlaku untuk konten yang dibuat dengan bantuan AI: draf soal atau pembahasan hasil AI tetap harus melalui alur yang sama, tidak dipublikasikan otomatis. Prinsip guru pegang kendali berlaku konsisten di sini — AI membantu membuat draf lebih cepat, tapi keputusan akhir tetap di tangan manusia yang memahami konteks kelas dan kurikulum institusi.

Tiga Tahap Alurnya

Setiap soal di bank soal Lesan melewati status berikut:

• Draft — soal masih dalam proses penulisan, bisa diedit bebas, belum terlihat siapa pun di luar penulisnya dan admin
• Diajukan untuk Review — penulis soal menandai soal sudah siap dicek, soal masuk antrean reviewer
• Disetujui (Published) — soal sudah lolos review dan bisa dipakai di asesmen langsung
• Ditolak — soal dikembalikan ke penulis dengan catatan revisi, statusnya kembali bisa diedit

Hanya soal berstatus Disetujui yang bisa dipilih saat menyusun asesmen. Ini mencegah soal yang belum final — misalnya kunci jawaban belum dicek ulang, atau pembahasan belum lengkap — tanpa sengaja terpakai karena penulisnya lupa statusnya masih draft.

Siapa yang Boleh Mereview dan Menyetujui?

Di level peran, reviewer biasanya dipegang oleh Admin atau guru senior yang ditunjuk sebagai koordinator mata pelajaran — bukan berarti guru penulis soal tidak bisa jadi reviewer untuk soal guru lain, tapi praktik yang lebih sehat adalah memisahkan penulis dan penyetuju untuk soal yang sama, supaya ada pasang mata kedua yang independen. Untuk institusi kecil dengan satu atau dua guru per mata pelajaran, peran ini kadang tumpang tindih — dan itu wajar, asal disadari bahwa proses review jadi kurang efektif kalau penulis mereview soalnya sendiri.

Supaya Review Tidak Jadi Bottleneck

Alur review paling sering macet ketika soal direview satu per satu, dalam urutan random, tanpa jadwal yang jelas. Beberapa praktik yang membantu:

• Review dalam batch per topik atau per bab, bukan satu soal begitu diajukan — ini membuat reviewer bisa membandingkan konsistensi tingkat kesulitan antar soal sekaligus
• Menjadwalkan sesi review rutin, misalnya tiap Jumat sore, alih-alih menunggu soal menumpuk sebelum tryout mendekat
• Menetapkan target: soal yang diajukan sebelum hari Rabu harus sudah direview sebelum akhir minggu
• Memberi catatan revisi yang spesifik saat menolak, bukan sekadar "perbaiki lagi", supaya penulis tidak bolak-balik menebak

Bottleneck yang paling merusak biasanya terjadi mendekati tanggal tryout, ketika puluhan soal diajukan mendadak dan reviewer kewalahan. Menjadwalkan target pengisian bank soal jauh-jauh hari — bukan seminggu sebelum tryout — adalah cara paling praktis menghindari ini.

Apa yang Terjadi Kalau Soal Ditolak?

Soal yang ditolak kembali ke status yang bisa diedit penulisnya, lengkap dengan catatan dari reviewer. Ini bukan soal "gagal" secara permanen — siklus Draft, Diajukan, Ditolak, revisi, lalu diajukan lagi adalah bagian normal dari proses, terutama untuk soal HOTS (higher order thinking skills) yang memang butuh beberapa putaran penyempurnaan sebelum pembahasannya benar-benar jelas dibaca siswa.

Contoh Skenario: Tryout UTBK Mingguan

Bayangkan sebuah bimbel yang menjalankan tryout UTBK setiap Sabtu. Tim penulis soal terdiri dari lima guru, masing-masing bertanggung jawab atas satu subtes. Kalau kelima guru ini menulis dan langsung mempublikasikan soal masing-masing tanpa saling mengecek, ada risiko standar kesulitan antar subtes jadi tidak konsisten — subtes Penalaran Matematika terasa jauh lebih sulit dibanding Literasi Bahasa Indonesia, padahal keduanya seharusnya setara secara tingkat kesulitan untuk tryout yang sama.

Dengan alur review, koordinator akademik bisa mengecek seluruh soal yang diajukan untuk tryout minggu itu sekaligus, membandingkan tingkat kesulitan antar subtes sebelum menyetujui semuanya bersamaan. Kalau ditemukan satu subtes terasa timpang, koordinator bisa menahan approval subtes itu saja sambil meminta revisi, tanpa mengganggu subtes lain yang sudah siap.

Pola ini juga membantu ketika bimbel punya banyak cabang yang berbagi bank soal pusat. Guru di cabang berbeda bisa mengajukan soal ke bank soal yang sama, tapi tetap ada satu titik kendali mutu terpusat sebelum soal tersebar dipakai di seluruh cabang.

Alur review ini memang menambah satu langkah dibanding sekadar menulis lalu langsung publish. Tapi dalam praktiknya, institusi yang sudah menjalankan kontrol kualitas semacam ini secara manual — biasanya lewat proses yang tidak terdokumentasi — akan merasa alur di Lesan justru mempercepat, karena semua status dan riwayat revisi tercatat di satu tempat, bukan tersebar di chat atau dokumen terpisah.