RGB Product Management Framework

Dalam pengembangan sebuah product, dalam hal ini terkait product management, maka diperlukan sebuah acuan, metode, pola dan kerangka kerja. Selama ini saya dan kolega menggunakan product management framework yang saya susun berdasarkan pengalaman, feedback, dan pembelajaran dari berbagai sumber, sehingga menghasilkan apa yang saya sebut RGB Framework dalam pengembangan sebuah product.

Kenapa disebut RGB Framework?

 

Istilah RGB terinspirasi dari standar sRGB yang dikembangkan di tahun 1996 oleh HP dan Microsoft di berbagai perangkat elektronik sebagai sebuah standar visual yang ditampilkan pada berbagai macam layar monitor, komputer, perangkat printer, kamera, scanner, dsb. RGB itu sendiri merupakan singkatan dari red, green, dan blue yang menjadi standar visual yang merupakan kombinasi dari warna merah, hijau, dan biru sebagai susunan warna yang digunakan. Dengan adanya sRGB, maka semua perangkat ketika itu menggunakan standar yang sama dan memudahkan semua pihak terkait.

Dari inspirasi tersebut, saya pun dalam bekerja sekaligus mempelajari berbagai standar dalam pengembangan sistem, aplikasi, hingga ke tahap era product development banyak menemukan berbagai acuan dan panduan yang berbeda-beda, dan memiliki kelebihan masing-masing.

Orde Lama SDLC (Waterfall)

 

Waterfall Model (Wikipedia)

Alhamdulillah saya diberikan kesempatan merasakan implementasi metodologi yang termahsyur di jamannya, kala itu SDLC (System Development Life Cycle) yang umum digunakan yaitu metodologi waterfall yang digunakan sekitar 6-7 tahun lalu diberbagai proyek pengembangan sistem.

Metodologi waterfall menurut Project Management Institue dijelaskan secara singkat bahwa sebuah aktivitas pengembangan dan pembangunan (baik di ranah software development, maupun pengembangan bisnis secara keseluruhan) yang dilakukan secara sequential, yaitu bertahap dari 1 fase ke fase yang lain secara berurutan. Kenapa disebut waterfall, karena alur dari metodologi ini mengalir layaknya air terjun yang jatuh dari tempat tinggi ke tempat lebih rendah. Meski banyak metodologi proyek (pengembangan sistem) yang telah ada, namun kepopuleran si air terjun ini masif digunakan diberbagai proyek IT di berbagai perusahaan, dan waterfall dianggap sebagai nenek moyang (bagi saya pribadi) untuk metodologi pengembangan sistem.

 

Waterfall Methodology - Royce (PMI.org)
Waterfall Methodology – Royce (PMI.org)

Pengalaman Berair Terjun

Awal karier saya berkesempatan ikut dan berpartisipasi di berbagai proyek pengembangan baik dari sisi proses bisnis (business process analysis & improvement), pengembangan prosedur (SOP dan juklak serta turunannya), hingga pengembangan sistem berbasis teknologi informasi bisa berupa aplikasi, portal, hingga level ERP yang masif.

Ketika itu, tahap awal biasanya dilakukan pertemuan besar yang mengumpulkan semua pihak yang terlibat, dan yang biasa disebut kick off meeting, di meeting tersebut merupakan tahap inisiasi awal memulai sebuah proyek, yaitu dijelaskan mengenai siapa saja yang bertanggung jawab, apa saja yang dikerjakan dan harus di-deliver, berapa lama estimasi waktu proyek dijalankan, gambaran besar teknis pengerjaan, do & donts dalam aktivitas tersebut, hingga soal standar pengerjaan, dokumentasi dan resources lain yang digunakan.

Tahap awalnya yaitu mengumpulkan kebutuhan user (user requirement) yaitu mencari serta mendefinisikan isu dan menentukan akar masalah (kalau di era agile, biasa disebut pain point oleh teman-teman product & UX), lalu dilakukan assesment kemudian dilakukan tahap desain, yaitu memberikan solusi dan rekomendasi. Di tahap ini banyak yang berperan yaitu teman-teman PMO/project manager bersama system architect, analis bisnis dan analis sistem, berinteraksi dengan teman-teman bisnis dan end user.

Setelah itu, masuk ke tahap pengembangan (development), dimana para developer aka engineer, teman-teman DBA, dan terkadang teman-teman Infra bekerja berkolaborasi dengan teman-teman analis dan architect, dibantu PMO. Kemudian setelah itu, dilakukan periode testing atau UAT, di tahap ini saya pribadi terkadang mengalami nervous, karena semua effort berbulan-bulan yang menguras waktu, tenaga, pikiran dan semua pekerjaan yang dilakukan ditentukan di tahap ini, dimana apa yang menjadi masalah dapat terlihat solusinya. Di tahap ini, teman-teman tester/QA bersama teman-teman analis berkoordinasi dibantu PMO bersama teman-teman bisnis bekerja sama dalam menyusuri tahapan ini.

Jika lolos tahap ini, maka dilakukan proses implementasi ke production dan mulai digunakan oleh real user di lapangan, lalu masuk periode maintenance, serta tentunya ditahap ini pun invoice mulai dikirim, billing diproses, dan terkadang reward aka bonus sudah riuh didiskusikanĀ  šŸ˜€

Orde Baru Pengembangan Sistem

 

scrum framework
Scrum Framework (Scrum.org)

 

Sesuai penjelasan di awal, maka semua tahapan di orde lama SDLC waterfall tersebut umumnya berjalan berurutan, layaknya air terjun yang jatuh dari atas ke bawah hingga tahap implementasi. Nah, kemudian masuk ke era agile yang populer digunakan yaitu metodologi Scrum yang dilakukan secara iterasi berulang, dan dilakukan dalam periode waktu tetap sesuai kebutuhan dan kemampuan tim development tersebut, hingga dapat mencapai hasil kumulatif di setiap siklus pengembangan yang biasa disebut sprint tersebut.

Ketika ber-scrum ria ada tahapan awal yaitu di sisi sprint planning, yaitu menentukan apa yang mau dikembangkan dan estimasi output yang dihasilkan beserta definisi dari sebuah hasil yang diinginkan, biasanya penentuan apa yang dikembangkan berbasis dari daftar semua request dan kebutuhan user yang disebut product backlog,

Selain itu, ada beberapa aktivitas rutin yang dilakukan semisal daily standup di periode development tersebut dan di akhir sprint ada tahapan review (atau bisa disebut testing juga), lalu masuk ke tahap evaluasi disebut retrospective yang menurut saya menarik dan sangat berbeda dari sisi filosofi pengembangan sistem, yang lebih ke arah hubungan antar role yang terlibat dan ujung-ujungnya membuat teamwork di tim semakin padu dan solid, karena dari filosofinya Scrum menghasilkan sebuah hasil kumulatif dari proses yang dijalani.

Finally The RGB Framework

Belajar dari pengalaman dan praktik langsung, maka saya akhirnya menyusun apa yang disebut RGB Framework yang mencoba mengambil hal baik dan positif dari yang sebelumnya dan sedikit melakukan modifikasi untuk pengembangan selanjutnya, dan bahkan saya menganggap framework ini layaknya living document yang suatu saat bisa disesuaikan dengan kebutuhan dan perkembangan kedepannya.

FYI RGB Framework ini disusun dari sudut pandang seseorang yang memiliki role di Product Management, seperti yang pernah saya bahas di artikel ‘Menjadi Seorang Product Manager’. Meski framework ini dibuat dari sisi Product Person, menurut saya bisa digunakan sebagai acuan bagi seorang Project Manager atau PMO (Project Management Office/Officer), Scrum Master, Agile Facilitator, Program Management, atau bahkan dari sisi teman-teman di Tech seperti role Developer/Engineer.

RGB Framework for Product Management - Ardika Percha
RGB Framework for Product Management

Framework ini banyak menyerap beberapa konsep dari metodologi yang lebih senior lainnya yang sudah ada yaitu sbb :

  1. ritual agile Scrum terkait dengan konsep sprint development, daily standup, sprint planning, sprint review, dan sprint retro dilakukan tim product dengan tim bisnis maupun tim product dengan tim tech maupun kombinasinya. Penggunaan filosofi Agile ini merupakan roh utama RGB framework secara keseluruhan, namun banyak digunakan di area Green dan Blue.
  2. konsep agile Kanban terkait flow request/feedback/task untuk penggunaan internal tim Product, maka semua pekerjaan dikelola dengan metode Kanban ini sesuai load dan capacity serta tentunya prioritas yang sudah dibuat merujuk ke roadmap besarannya. Penggunaan konsep ini banyak digunakan di area Red dan Green.
  3. lalu karena saya cukup banyak terpapar dengan SDLC Waterfall yang kena racun Agile Scrum juga, maka midset saya untuk memudahkan dalam pengerjaan diterapkan pemisahan antara satu area ke area lain. Untuk coontohnya ketika sebuah user story untuk suatu feature sudah masuk ke area Green atau Blue, maka akan hal tersebut akan terus berjalan hingga nanti terimplementasi. So, check point-nya ada di tahap Go or Not Go tersebut, yaitu di area Red danĀ  area Green, dan yang menjadi key point, maka dalam satu area pekerjaan pengembangannya bisa dilakukan bolak-balik maju mundur, misal di area Red sudah masuk tahap nomor 3 yaitu product research, ternyata harus dilakukan reprioritasi misalnya di product roadmapnya, maka mundur lagi ke tahap nomor 2 yaitu product roadmap review.

So, di framework ini dibagi menjadi 3 kelompok besar berdasarkan urutan RGB tersebut yaitu sbb :

#1 Iterasi & Alur Area Red

Di area ini, maka bisa disebut sebagai fase gather requirement, assesment, riset, dan analisis yang banyak berkutat di area WHY dan Issue Definition. Di lingkup area ini, maka tim Product akan menerima request/feedback dari berbagai pihak baik internal maupu eksternal termasuk end user, klien, maupun customer. Selain menerima input dari pihak luar tim Product, paralel tim product pun melakukan assesment, riset, dan analisis dibantu oleh data fakta dari tim Data mapun berdasar masukan dari riset yang dilakukan tim UX.

Dari input baik internal maupun eksternal tersebut menjadi materi dan dirangkum menjadi sebuah requirement atau user story dan menjadi input ke Backlog.

Di area ini juga Product person (termasuk tim UX dan Data) bersama tim bisnis terkait akan banyak saling berdiskusi, terkadang meminta feedback dari berbagai subject matter expert termasuk tim Tech, Operation, Business Development, sampai ke Finance.

Dari semua finding, feedback, dan request yang ada di Backlog tersebut harus dikelola, diatur, dan diprioritaskan dalam sebuah roadmap product development yang menjadi acuan jangka panjang dalam pengembangan product tersebut, dan ini harus disesuaikan dengan Product Vision yang merupakan turunan dari company objective (ada sebagian menyebutnya Northstar).

End point dari area Red ini, maka sebuah Product Backlog yang sudah difilter berdasar berbagai variabel yang ditentukan, apakah sebuah user story ini memang memiliki impact atau bahkan memberikan value ke bisnis dan/atau end user berdasar hasil riset dan analisis yang telah dilakukan. Keputusan Go atau Not Go pun harus ditentukan sebelum masuk ke area Green, dan ketika ditemukan suatu finding baru atau feedback, bisa jadi prosesnya mundur ke tahapan sebelumnya, misalnya diperlukan konfirmasi dan data dari perspektif berbeda, jadi sifatnya fleksibel dan dinamis.

#2 Iterasi & Alur Area Green

Di area Green ini, maka user story atau requirement yang ada sudah cukup jelas dan masuk ke tahapan UI development. Di tahap ini bisa jadi sudah tidak Low-Fi UI, namun bahkan sudah tahap prototipe yang dilakukan oleh tim UI dibantu tim UX, dan semakin detail dari setiap komponen di solusi yang nanti akan dikembangkan.

Di tahap ini solusi yang ditawarkan sudah jelas baik dari sisi input, proses yang berkaitan, sampai output dan deliverable yang diinginkan, bahkan sampai tahap copy dan dialog message misalnya, atau micro interaction yang digunakan sudah ditentukan dan finalisasi melalui beragam metode acceptance test atau user testing antara tim Product dengan end user. Salah satu poin penting yaitu penentuan tingkat acceptance yang nanti diterima, bahkan penentuan definition done juga sudah mulai dipikirkan dari sisi tim product tersebut.

End point dari area Green ini yaitu user story yang nanti akan masuk ke area tech developmnet planning (analoginya di metodologi Agile Scrum yaitu di tahap Sprint Planning). Nah.. keputusan Go or Not Go ini ada ketika sprint planning, ketika terjadi diskusi (bahkan debat konstruktif?) antara tim Product terkait dengan tim Tech yang difasilitasi oleh atau tim PMO ( Scrum Master di analogi metodologi Scrum).

Ketika user story tersbut sudah disepakati dan ditentukan oleh Scrum Master, maka user stroy itu pun berpindah dari product backlog masuk sprint backlog yang akan masuk ke siklus iterasi berikutnya.

#3 Iterasi & Alur Area Blue

Nah.. di area Blue ini sudah masuk ke tahap development hingga implementasi nanti termasuk ketika tahap review dan UAT bisa masuk ke tahapan di area Blue ini, namun yang menjadi perhatian, ketika di tahap development, maka mostly sudah fixed dan sulit untuk ada perubahan major, karena masuk dalam tahap coding oleh teman-teman Engineer/Developer.

End point di area Blue ini, maka user story tadi sudah di-deliver dan terimplementasi ke production dan digunakan oleh end user, kemudian masuk ke tahap post implementation, dan ada kalanya ditemukan beberapa feedabck untuk improvement kedepannya sehingga masuk kembali ke area Red diawal tadi.


RGB Framework ini seperti yang diuraikan sebelumnya, merupakan pengalaman saya (baca: trial-error & trial-proven experience) selama ini, yang pada awalnya digunakan untuk kebutuhan saya pribadi dan tim dengan role Product Management ditempat kerja sebelumnya . Lalu di kantor berikutnya dengan roleĀ sebagai Product LeadĀ ada kesempatan untuk melakukan formulasiĀ  metode kerja bersama tim Product serta adanya kebutuhan saat itu untuk membuat semacam standar prosedur dan panduan bagi tim Product dalamĀ  proses development dari fase awal hingga tahap implementasi di salah satu startup e-Commerce & Logistic.

RGB Framework yang telah disusun dan dikembangkan sebelumnya, akhirnya disempurnakan dengan berkolaborasi dan kerja bareng di fase brainstorming bersama teman-teman tim Product ketika itu yaitu :

  1. Rizky Adyasa sebagai Product Management Specialist
  2. Putri Widya sebagai UI Designer
  3. Kevin Julianto sebagai UX Designer/Researcher
  4. Devin Pradipta sebagai UX Designer/Researcher

Dengan membagikan informasi mengenai RGB Framework ini Insya Allah bisa berguna bagi handai taulan sekalian dalam penerapan metodologi product development.

Selain itu, jika ada masukan plus umpan balik konstruktif untuk melengkapi dan menyempurnakan framework ini, saya berterima kasih dan sekaligus bersyukur sehingga dapat bermanfaat bagi publik.

Untuk komunikasi, masukan, dan umpan balik bisa menghubungi via japri : saya@ardikapercha.com


Referensi :

  1. https://www.w3.org/Graphics/Color/sRGB.html
  2. https://www.pmi.org/learning/library/agile-project-management-pmbok-waterfall-7042
  3. https://www.scrum.org/resources/what-is-scrum/

Change Log :

  • Versi 1.0 Publikasi dan rilis perdana di Blog – April 2020
  • Versi 1.1 Penambahan detil informasi di poin Iterasi & Alur RGB –Ā  Mei 2020
  • Versi 1.2 Penambahan informasi kredit ke tim Product ex-Oktagon & Penutup – Juli 2020

 

Ayo Kasih Komentar Dong - Leave a Reply