Pengertian PRD RFC Proses Produk dan Fitur Dirilis
Pengertian PRD RFC Proses Fitur Bisa Dirilis Product / Feature Development - Jadi kapn hari, saya liat twit Mas Frans yg pingin tau tentang pengalaman kerja di sebuah fast-growing startup, spesifiknya bagaimana proses sebuah fitur bisa di-release.
PRD: problem requirements document
RFC: request for comment
Nah, ini janji saya ke Mas Frans untuk share soal itu.
Sebelumnya, saya perlu kasih konteks dulu. Saya saat ini bekerja di sebuah perusahaan yang sudah berstatus "jagung".
Jadi proses yang saya ceritakan mungkin akan agak berbeda dengan perusahaan yang masih di fase berbeda, dengan korporat, atau dengan instansi plat merah.
Bedanya di mana? Kalau menurut saya, dibanding dengan startup yang masih di fase awal (seed, series A, series B), perusahaan jagung cenderung lebih lembam, tidak selincah startup yang masih di fase awal.
Di startup yg masih fase awal, dari ide sampai release prosesnya cenderung lebih cepat dan tidak banyak "birokrasi" yang mesti dilalui. Di perusahaan jagung, sudah mulai kelihatan ada birokrasi. Dan ini sebenarnya buat saya hal yang netral saja, tidak positif, tidak negatif.
Kenapa begitu? Kemungkinan besar karena ukuran.
Di startup fase awal, boleh jadi semua orang masih punya akses langsung ke C-level dan founder. Founder punya ide, bisa langsung diobrolin ke semua orang, langsung dieksekusi, langsung di-release.
Dampak perubahan pun relatif mudah diobrolin ke semua orang, boleh jadi semua orang yang perlu dikasih tau tentang sebuah perubahan ada di ruangan atau di channel Slack yg sama. Jadi mungkin justified juga kalau ga perlu mekanisme yg terlalu "birokratis".
Di perusahaan jagung mungkin sudah agak beda. Akses ke founder barangkali cuma via townhall, misalnya. Jadi dari ide sampai ke eksekusi itu ngelewatin beberapa lapis birokrasi. C-level, HoX (head of X), lead/manager, baru sampai ke engineer.
Mekanisme yg agak "birokratis" diperlukan untuk meminimalisir terjadinya distorsi visi/ide/strategi di rantai komunikasi yg agak panjang tadi.
Di perusahaan jagung, karena ukurannya yang sudah relatif besar, dampak perubahan juga jadi besar. Misal kita mau release versi baru dari service kita, tentu tim-tim lain yg service-nya bergantung sama service kita ini perlu dikasih tau.
Boleh jadi orang-orang yg perlu kita kasih tau tadi ga ada di Slack channel, ruangan, gedung, atau bahkan negara yg sama dengan kita.
Pada kadar tertentu, mekanisme yg agak "birokratis" diperlukan untuk diseminasi informasi di sini.
Sementara, dibandingkan dengan korporat besar atau instansi plat merah, menurut saya, perusahaan jagung masih jauh lebih lincah. Di luar penentuan company level OKR, banyak hal masih bersifat cair.
Bahkan dalam menentukan "fitur apa yg perlu kita buat untuk mencapai OKR X?". Di perusahaan jagung masih banyak yg prosesnya bottom up. Paling tidak begitu yg saya rasakan di kantor sekarang.
Oke, tadi konteksnya udah ya. Dengan konteks tadi, praktek nge-release fitur di perusahaan jagung masih relevan untuk menggunakan lean methodology sebagai underlying principles-nya. Tapi sebenernya, apa sih lean methodology itu?
Secara singkat, konsep ini buat saya adalah cara untuk develop dan rilis sesuatu di tengah uncertainty.
Startup kan, kalau secara definisi, mengerjakan sesuatu yang belum tervalidasi. Maka mayoritas metode yang dipakai startup itu tujuannya untuk menjadikan perubahan "murah".
Dengan lean methodology, kita ga berasumsi bahwa kita tau pasti apa yg bakal diterima pasar. Maka siklusnya adalah build, meassure, learn.
Kita bikin dulu hal yg minimal perlu (MVP isitlahnya), kita release, kita ukur apakah metric-metric yg kita ingin dari produk/fitur kita tercapai, kemudian kita perbaiki lagi produk/fitur kita di iterasi berikutnya.
Praktek-praktek yg nanti saya bahas didasari dari sini.
Nah, sekarang kita masuk ke praktek ya. Akhirnya.Grinning face with smiling eyes
Apa aja praktek yang dilakukan oleh perusahaan jagung dalam merilis produk/fitur?
Pertama, tentu dari OKR. Di kantor saya sekarang, OKR cuma ada dua level: group OKR dan company wide OKR. Saya menghindari menyebut merk, tapi semoga temen-temen ngeh ya group itu yg mana, company yg mana. Hehe.
Setelah ada company level OKR, semua unit yg di bawah itu kemudian diminta untuk membuat inisiatif-inisiatif yg berkontribusi terhadap key result tertentu.
Dalam mengusulkan inisiatif, biasanya kita pake PRD + RFC. Ada beberapa definisi berbeda tentang PRD dan RFC. Kalau di tim saya, kita pake definisi yg sama dengan yg di link HashiCorp di bawah.
PRD: problem requirements document
RFC: request for comment
PRD itu tempat kita mengutarakan "the why" dari fitur/produk yang mau kita bikin. Di tim kami, beberapa hal yang biasanya perlu dijelaskan adalah:
- kondisi saat ini
- kenapa ini bermasalah atau perlu diperbaiki
- bagaimana kondisi ideal kalo hal ini kita perbaiki
- kesimpulan
Saya kasih contoh ya...
Nah, itu tadi tentu tiap bagian perlu dielaborasi lagi. Bagian current situation, misal, bisa kita elaborasi dengan informasi tentang berapa waktu rata-rata yg diperluin satu agent untuk verifikasi. Berapa % komplain yg kita terima dari user ketika ada verifikasi yg keliru. Etc.
Oke, sekarang kita lanjut ke RFC. Di RFC ini baru kita menjelaskan detil solusinya. Kadang, satu PRD bisa jadi beberapa RFC. Misal, dari contoh tadi, kita bisa punya RFC yang terpisah untuk otomasi proses A, B, C masing-masing tuh. Bisa juga satu RFC aja.
Ya, disesuaikan dengan scope dan konteks aja. Kalau otomasi proses A scope-nya udah besar sendiri, RFC-nya dipisah aja. Kalau kita perlu cepet dan kelihatannya otomasi fitur B perlu diprioritasin, RFC-nya diduluin yg B aja.
Konten yg perlu ada di RFC:
- alternatif solusi apa saja yg sudah kita pertimbangkan
- apa alternatif yg jadi pilihan kita dan kenapa kita pilih itu
- detil teknis yg relevan (bisa berupa arsitektur, snippet kode yg penting, API contract, etc)
PRD dan RFC biasanya dibahas tiap minggu. Idealnya < 2 minggu proses approval-nya. Yg utama diinget adalah tujuannya untuk memastikan dua hal:
- kita ngerjain hal yg benar (contributing to company OKR)
- semua pihak yg terkait bener-bener tau dampak dari produk/fitur baru kita
Kadang, ketika kita bikin PRD dan atau RFC, kita memerlukan proses yang namanya spike. Proses ini adalah proses prototyping di mana kita menguji beberapa alternatif solusi/implmentasi.
Misal, kita mau otomasi proses verifikasi sebuah dokumen. Misal lagi, ternyata ada beberapa alternatif:
- 3rd party library yg specialized u. jenis dokumen itu
- 3rd party library yg general untuk image to text processing
- bikin sendiri library untuk image to text processing
Ketika spike, kita memverifikasi hal-hal yg perlu kita tahu: does it work, at what cost, etc.
Bisa jadi pake specialized 3rd party library ternyata langsung solved, tapi mahal banget. Bisa jadi bikin library sendiri murah, tapi lama (jadi ada opportunity cost di situ). Bisa jadi pake generic 3rd party ternyata yg balanced, ga terlalu mahal dan bisa kita develop cepet.
Karakteristik utama dari spike adalah kecepatan. Yg penting hal-hal yg kita perlu verifikasi beneran verified. Jadi kodenya ga perlu rapi. Haha. Tapi habis itu, ya harus di-discard hasil spike-nya. Mulai lagi development yg bener setelah ditentukan mau pake alternatif yg mana.
ketika nyusun RFC & PRD itu butuh waktu 2 minggu, siapa aja yg terlibat di sini? Proses ini berlangsung tiap sprint?
Kenyataan di lapangan ga selalu < 2 minggu, Mas. Yg bikin PRD + RFC biasanya engineer (including lead/engineering manager) + PM. Approval tergantung scope. Kalau itu internal tim, yg approve cukup lead/manager. Kalau agak besar, HoX atau hirarki apa pun di atas lead/manager.
Posting Komentar