Hi Tech Enthusiast! Perkenalkan, saya Rudi Sanjaya, Digital Banking Consumer Product Lead, Bank SMBC Indonesia. Dalam Tech Monday Updates kali ini saya mau bercerita tentang bagaimana Jenius melakukan pengembangan produk. 

Dalam pengembangan produk berbasis teknologi, beberapa metodologi diperkenalkan dan digunakan oleh berbagai organisasi. Mulai dari waterfall, scrum, agile, RAD (rapid application development), prototype, sampai DevOps. Berbagai pendekatan metode digunakan oleh organisasi mengikuti kemampuan, kapasitas, dan seberapa cepat produk dapat diluncurkan. 

Jenius sebagai salah satu aplikasi keuangan menggunakan metode scrum dengan beberapa modifikasi. Saya gak bakal membahas secara detail mengenai teori mengenai scrum, tapi lebih ke arah bagaimana seorang product owner atau product manager melakukan manajemen terhadap proses ini. Scrum di Jenius bisa dikatakan adopsi proses waterfall, yang mana ruang lingkup pekerjaan dilakukan diperkecil dengan waktu yang ditentukan yaitu 2 minggu.

Sebagai product owner, sangat penting untuk bisa paham bagaimana melakukan perencanaan pengembangan, terutama bagian-bagian yang akan dikembangkan. Bayangkan kalau hendak bikin sebuah rumah, apa yang mesti kamu persiapkan? Pintu, kusen, jendela, dinding, taman, atap, furnitur, dan lain sebagainya. Product owner ini melakukan breakdown terhadap produk ke tahapan-tahapan pengembangan dan menjadikan masing-masing tahapan menjadi kepingan puzzle yang nanti akan disusun kembali di proses development. 

Produk atau fitur dapat dibagi menjadi beberapa tahapan pengembangan yang bertujuan untuk meminimalisasi dampak perubahan, mengukur penerimaan user, kapasitas infrastruktur, penggunaan fitur, dan dampaknya terhadap bisnis secara keseluruhan. Perjalanan pengembangan produk sering dihadapkan pada situasi ketika terdapat perubahan yang terjadi akibat permintaan dari user, adanya perubahan regulasi, perubahan pasar, dan lain sebagainya. 

Berikut adalah beberapa hal yang bisa dilakukan oleh product owner dalam proses pengembangan produk, khususnya di Jenius. 

Pre-Sprint

1. Jauh sebelum sprint dimulai, produk atau fitur telah melewati proses cukup panjang sebelum memperoleh desain yang akan dikembangkan. Selanjutnya product owner menentukan bagian-bagian mana yang akan dikembangkan secara bertahap ke dalam backlog.
2. Sebelum sprint dimulai, sebaiknya tentukan dan sepakati definition of done (DoD) dari sprint. Secara umum, DoD adalah kesepakatan bersama untuk menentukan pada tahap apa sebuah backlog dinyatakan selesai dikerjakan di dalam sprint. Menentukan DoD sebuah sprint akan berbeda antara 1 organisasi dengan organisasi lainnya. Hal ini juga sangat tergantung dari proses, infrastruktur, dan kebutuhan tim. DoD bisa ditentukan top down atau ditentukan sendiri oleh anggota yang berpartisipasi di dalam sprint. DoD bukan cuma mencakup mengenai development, tapi juga hal-hal yang terkait dengan pengembangan produk. Contoh dari DoD sprint adalah setiap story atau backlog harus diselesaikan pada sprint berjalan dengan status PO verified, sudah dilakukan testing, atau bahkan sudah melalui proses UAT. DoD menjadi hal yang esensial dalam sprint karena akan menjadi tolok ukur kesuksesan sprint, kemampuan tim secara keseluruhan, dan banyak hal lainya.
3. Menentukan story yang diambil. Salah satu tugas product owner adalah menentukan story yang akan dikerjakan pada sprint berjalan. Mengingat sprint adalah kolaboratif effort, maka PO dapat mendiskusikannya dengan sebagian atau seluruh tim mengenai story yang dikerjakan melalui proses grooming. Kalau story terlalu rumit, maka bisa dibagi menjadi beberapa story untuk memudahkan dalam proses pengerjaan. Sebagai contoh, pada sprint ini bakal mengerjakan halaman login; mengingat proses login terdiri atas pengisian user dan password, proses verifikasi user, hasil normal, hasil negatif, aksi setelah user terverifikasi, dan seterusnya. Story tersebut dapat dibagi menjadi beberapa story untuk memudahkan proses pengembangan.
4. Setelah story ditentukan, maka proses selanjutnya adalah melakukan yang disebut sebagai grooming. Grooming adalah proses membedah setiap story untuk menentukan kebutuhan dan berbagai aspek terutama dari sisi developer dan tester. Segala aspek mengenai story harus dapat digali mulai dari tampilan, kerumitan pengerjaan, arsitektur, implikasi story, test case, bahkan mungkin akan berdampak pada fitur yang lain. Story yang akan dikerjakan harus mengikuti DoD yang telah didefinisikan. Apabila sebuah story diidentifikasi memiliki tingkat kerumitan tinggi dan berpotensi carry over, maka product owner harus melakukan splitting story.
5. Visualisasi. Persiapkan segala hal terkait sprint secara visual, mulai dari story yang akan dikerjakan, siapa yang akan mengerjakan dan estimasi pengerjaan. Visualisasi ini memudahkan seluruh team melakukan monitoring kemajuan sprint sekaligus menentukan apakah pengembangan masih sesuai estimasi atau akan ada potensi terlambat.

Sprint

1. Monitoring. Product owner bersama tim melakukan check point untuk memonitor progres dari sprint melalui daily huddle. Aktivitas ini adalah untuk mengetahui sejauh mana proses pengembangan dilakukan dan apakah ada hambatan yang dihadapi oleh seluruh tim.
2. Persiapan sprint selanjutnya. Selama masa sprint berjalan, maka product owner juga melakukan persiapan sprint berikutnya.
3. Lain-lain. Selain fokus pada sprint, product owner bisa juga melakukan aktivitas terkait produk seperti persiapan hal-hal nonteknis seperti kebutuhan regulasi, komunikasi produk, dan investigasi terhadap isu produk yang sudah diluncurkan.
   

Post-Sprint

1. Review. Bersama dengan seluruh tim, perwakilan stakeholder dan beberapa tim lain melakukan review hasil pengembangan yang dilakukan di sprint. Di dalam proses review diperoleh berbagai feedback mengenai hasil dan apabila diperlukan dimasukkan sebagai backlog.
2. Retrospektif. Setelah hasil dipresentasikan dan diperoleh feedback, maka selanjutnya dilakukan proses review secara proses sprint. Apa saja yang pencapaian yang bisa dibanggakan secara team untuk dilanjutkan ke sprint selanjutnya maupun hambatan yang menyebabkan pekerjaan gak terselesaikan sesuai dengan estimasi. Hambatan bisa berupa infrastruktur pendukung, tim lain, maupun hal-hal yang bersifat nonteknis. Biasanya retrospektif akan dipimpin oleh scrum master dan nantinya hal-hal ini akan disampaikan dan dimonitor oleh scrum master.

Sprint buka cuma iterasi pengembangan produk, tapi juga iterasi pembelajaran untuk seluruh tim yang terlibat dan dapat dijadikan acuan untuk pengembangan yang lebih efisien. Berikut adalah pembelajaran yang bisa ditemui selama sprint:

1. Velocity, adalah jumlah story point yang bisa dicapai oleh tim dalam 1 sprint. Biasanya bisa didapat setelah dilakukan kurang lebih 4 sprint di awal dengan komposisi tim yang gak berubah.
2. Kendala yang sering dihadapi selama proses sprint dan solusi apa yang dapat dilakukan untuk menghindari kendala tersebut di kemudian hari.
3. Kemampuan tim dalam melakukan estimasi pekerjaan dan realisasi.
4. Kemampuan individu dalam menyelesaikan pekerjaan.
5. Komunikasi yang terbangun di dalam tim.
6. Dan masih banyak lagi pembelajaran yang bisa ditemui di dalam sprint.

 Cara kerja agile dengan menggunakan metode scrum seperti ini juga bisa kamu terapkan bersama tim lho! Biasanya kendala apa yang sering terjadi saat kamu dan tim mengembangkan sebuah produk? Jangan ragu untuk berbagi pengalamanmu di kolom komentar, ya!