Mengenal RFC: Pengertian dan cara membuatnya

RFC ( Request for Comments ) saat ini biasa dipakai sebagai dokumen yang mengusulkan perubahan besar atau fitur baru dalam suatu proyek. Dokumen ini menjelaskan secara detail tentang usulan perubahan teknis atau fitur baru, termasuk alasan, desain, dan dampaknya. Ini dipakai sebagai dasar diskusi sebelum implementasi.

RFC membantu tim dan stakeholder memahami ide atau perubahan yang akan dilakukan, memastikan setiap stakeholder setuju sebelum coding dimulai. RFC juga membantu untuk membuat brainstorming lebih dalam, sehingga potensi issue bisa diketahui lebih awal.

Dengan adanya dokumen RFC yang terstruktur, semua orang bisa:

• Memikirkan berbagai sudut pandang dan kemungkinan masalah yang mungkin terlewat tanpa diskusi formal.
• Menyumbang ide atau solusi alternatif yang mungkin lebih efisien atau aman.
• Mengidentifikasi potensi isu teknis, operasional, atau bisnis lebih awal sebelum mulai coding atau implementasi.
• Membangun konsensus bersama sehingga keputusan yang diambil jadi lebih kuat dan diterima oleh semua pihak.
• Memungkinkan tim melihat potensi risiko teknis, dampak pada sistem lain, atau efek pada performa sebelum implementasi. Jadi, tim bisa siap dengan mitigasi.
• Menjadi acuan standar kerja yang diikuti semua orang, terutama di organisasi besar atau proyek yang melibatkan banyak pihak.

Bagian - bagian pada dokumen RFC yang harus ada :

• Judul yang Jelas dan Singkat – langsung menjelaskan inti dari RFC. Contoh : " RFC : Fitur Login via OTP / Passwordless "
• Detail Author / Document – metadata
  • Author(s): Siapa yang menulis / mengusulkan RFC
  • Reviewers (opsional): Siapa yang mereview
  • Status: Draft / In Review / Accepted / Rejected / Implemented / Deprecated
  • Created Date
  • Last Updated
  • Related RFCs (jika ada RFC yang sebelumnya atau turunannya)
  • Discussion URL / Link ke PR / Issue tracker
• Ringkasan / Abstract – gambaran singkat tentang tujuan utama.
• Latar Belakang / Problem Statement – berisi masalah yang ada / ingin diselesaikan, dan tujuan dari penyelesaian kenapa perubahan ini diperlukan. Sebaiknya diisi secara detail sehingga permasalahan dapat mudah dipahami. Apabila perlu diberikan bukti seperti data analytic atau log tertentu.
• Proposal – Uraikan solusi atau desain yang diusulkan secara lengkap dan teknis. Pada bagian ini dibuat secara detail dan jelas langkah - langkah yang akan dilakukan. Misal berisi rencana pembuatan API baru, modifikasi API, menambahkan fitur baru, dll. Termasuk ada detail seperti
  • API Contract atau API Specification.
  • How to test
  • Rencana Rollout dan Rollback ( feature toggle, flagging )
• Dampak dan Risiko – uraikan kemungkinan dampak yang muncul dari penerapan RFC ini, baik positif maupun negatif. Misalnya, perubahan performa, kompatibilitas, keamanan, dsb.
  • Tuliskan sistem, modul, service, atau tim mana saja yang terdampak
  • Jangan lupa mencantumkan dampak terhadap user atau produk ( alasan bisnis )
• Rencana Implementasi dan Timeline – berikan langkah implementasi dan perkiraan waktu. Dalam implementasi SCRUM, biasanya bagian ini diisi dengan link ticket pengerjaan, dengan sudah di perjelas detail ticket + Story Point dan akan di kerjakan di Sprint berapa.
  • Timeline Development - Testing - Release
  • Ticket Task
• Alternatif yang Dipertimbangkan – apabila perlu / ada, uraikan opsi lain dengan di jelaskan pros & cons setiap opsi.
• Kesimpulan dan Ajakan Diskusi – dibagian akhir bisa di isi dengan kesimpulan / list pertanyaan apabila dalam pembuatan RFC masih ada beberapa point yang perlu didiskusikan ( Need to Ask / Need to Confirm ) sehingga ketika diskusi, semua tim bisa concern atas poin - poin tersebut.
  • Catat poin penting hasil diskusi jika RFC dibahas dalam forum/tim
• Referensi – apabila perlu, cantumkan dokumen, artikel, atau sumber lain yang relevan.

RFC bukan hanya soal dokumentasi, tapi juga alat kolaborasi yang penting untuk memastikan semua pihak memahami, mengevaluasi, dan menyepakati arah teknis yang akan diambil. Pembuatan RFC sangat membantu developer dalam melakukan pengembangan, dan menghindari adanya perubahan rencana. RFC juga sangat membantu untuk menghindari potensi issue yang baru di ketahui ketika development karena sudah dilakukan diskusi sebelumnya.

Diharapkan ketika RFC dibuat, semua tim termasuk tim produk juga menyetujui dan memahami pros cons terhadap development ini.

Point Penting! Dalam membuat RFC ini, pastikan setiap team memahami dan membaca dokumen dengan seksama, tidak sekedar "formalitas" dalam membuat RFC.