#S3: Rumusan Masalah

Lagi mau coba nulis apa-apa yang didapat selama S3 setelah jalan 3 tahun ini. Tiap dapat “hikmah” pas lagi S3 ini sering nyeletuk dalam hati, “oh kayaknya bagus ini ditulis biar keinget”, tapi Qaddarullah akhirnya lupa. Bismillah coba mulai ditulis satu satu, seingetnya.

Kalau diinget-inget, salah satu ilmu yang paling ngena selama S3 ini sebenernya bukan topik-topik riset saya, entah itu perkomputer arsitekturan, atau security, dsb. Tapi konsep riset itu sendiri. Sekarang kalau saya ditanya apa itu RISET? saya ngerasa RISET itu intinya: observasi suatu masalah, rumusin solusi, tunjukkan kalau solusi itu bisa menyelesaikan masalah itu.

Supervisor saya memecahnya sebagai “5 poin yang harus ditulis di paper”:

1. Apa masalah yang mau diselesaikan? kenapa itu penting?
2. Bagaimana solusi yang ada sekarang? kenapa itu tidak cukup?
3. Apa solusi yang mau kita tawarkan?
4. Kenapa solusi kita itu lebih baik dari solusi yang ada sekarang?
5. Apa insight dari hasil penelitian ini?

Dan selama S3 saya diajarin ketika membuat projek riset saya harus menanyakan dan menjawab poin-poin tersebut dengan benar. Saya bold, karena semakin jalan S3 ini, saya sadar kalau saya, yang sudah usia kepala 3, dosen, dan pernah “riset” ini, ternyata masih sering gagal menjawab pertanyaan itu.

Dari 5 poin tadi kita bisa kelompokkin dan cocokin sama definisi RISET ala saya tadi: Poin 1 dan 2 seputar observasi masalah, poin 3 tentang rumusan usulan kita, poin 4 an 5 tentang menunjukkan bahwa solusi kita itu bisa menyelsaikan masalah tadi.

Artikel ini cuma akan bahas bagian pertama, seputar masalah.

Riset Pertama Saya

Kalau diinget, riset pertama saya ketika S1 (dan kebanyakan riset-riset setelahnya) tidak betul-betul berangkat dari masalah. Tapi dari “oh saya tahu teknik baru X, bisa coba buat solve apa ya”. Paper pertama saya adalah pemanfaatan deep learning untuk pelafalan huruf hijaiyah. Saya berangkat dari belajar apa itu Deep Learning, lalu saya cari kasus apa yang mungkin menarik untuk diselesaikan, bagi saya waktu itu klasifikasi file audio.

Pas S3, cara pikir ini sempat muncul awal-awal, tapi nggak lama, karena cara pikir ini nggak akan bisa bikin usulan saya disetujui pembimbing, lah wong nggak bisa jawab pertanyaan pertama atau kedua di atas.

Konsep cari-cari masalah yang salah gini biasanya berefek:

1. Sebenarnya ada solusi yang lebih baik tapi karena fokus dengan teknik X, kita mengabaikan solusi-solusi lain itu.
2. Kurang realistik. masalah yang kita angkat itu sebenarnya bukan masalah utama.

Observasi Masalah

Dengan bekal dua pertanyaan dari supervisor saya, saya jadi bisa lihat kalau riset-riset di conference-conference besar itu kadang nggak selalu menyelesaikan masalah kompleks. Yang penting: masalahnya valid.

Contoh paper ringan yang baru-baru aja saya baca: https://ieeexplore.ieee.org/document/10771230. Apa masalah yang diangkat? AI untuk coding semakin banyak, bagaimana performa kode yang ditulis oleh AI di suatu sistem? lebih lambat kah? tetap aman kah? kebanyakan paper hanya menguji seberapa benar atau tidak kode yang ditulis, tetapi mengabaikan pengukuran kualitas kodenya. Perlu ada pengujian untuk mengukur performa kode yang ditulis oleh AI.

Bagi yang punya pengalaman ngoding, nggak perlu punya pengalaman riset, atau lulusan kampus top, masalah yang diangkat di paper tadi bisa kebayang. Mungkin beberapa dari kita bisa langsung kebayang gimana cara ngujinya. Paper itu keterima di salah satu conference besar di software reliability dan ditulis dari kampus besar dunia.

Cari Masalah (Yang Valid) itu Perlu Usaha

Saya pernah baca status dari penggiat industri di Indonesia ketika sistem yang dia kelola tiba-tiba ada masalah. Dia sarankan lakukan Root Cause Analysis dengan menanyakan 5 why.

Untuk menjawab pertanyaan pertama dari supervisor saya: “Apa masalah yang mau diselesaikan? kenapa itu penting?” kita kadang perlu usaha yang nggak sedikit. Bisa jadi sudah harus ngoding, ngelakuin eksperimen, atau sampai reproduksi paper orang. Semua demi cari dan validasi suatu masalah. Dan setelah semua usaha itu, masih ada kemungkinan berakhir “oh, ternyata ini bukan masalah” dan akhirnya harus cari-cari lagi.

Refleksi

• S3 nyadarin kalau sebenernya ilmu riset itu bukan cuma riset di akademik. Di poin pertama tentang observasi masalah, intinya kita mau tahu apa benar itu suatu masalah dan apa penyebabnya. Dan kita bisa terapin ini di mana aja, misal ketika kita mau ikut lomba bikin aplikasi, atau buat startup, atau buat kebijakan suatu organisasi. Bisa coba renungin, sebenernya masalah apa yang mau disolve? beneran masalah kah? beneran penting? apa emang nggak ada solusi yang lebih baik?
• Beberapa riset saya, saya akui bukan berasal dari masalah yang valid. Beberapa niatnya cuma untuk “latihan” teknik baru yang saya pelajari. Uniknya, beberapa keterima di conference, bahkan ada yang keterima di Jurnal Scopus Q2. Ini jadi ngingetin, kalau paper yang udah keterima di suatu conference pun belum tentu punya masalah valid yang diangkat. Ini kayaknya jadi intro artikel selanjutnya.

Penutup

Sebenernya bahasan tentang masalah ini bahasan kedua di blog ini setelah sebelumnya saya dibuat takjub sama pemilihan-pemilihan masalah di ISCA di tahun pertama S3 saya. Artikel ini nunjukin setelah 3 tahun di sini, ternyata konsep perumusan masalah di suatu penelitian emang penting. Saya sadar saya juga bukan yang ideal di pemilihan masalah di penelitian, tapi konsep ini ilmu yang saya dapat di sini, jadi ya sebaiknya dicatat dan dibagi siapa tahu bermanfaat. Wallahu a’lam.