Thank you for give us a message ! We’ll reach you as soon as possible.

Back to Home Page
Work with us
Apply as Freelancer
Got Question ?

You have read our website and still have question(s) left. Please, don’t be shy and ask us.

What can we do for you? We would love to listen and discuss your concerns. Let’s collaborate and make right product for your business.


If you like to work with new people and have passion to turn a challenge into something awesome, join us!

Jalan Titiran 7, Bandung 40133, West Java, Indonesia +62-22-2531318 hello@labtekindie.com

Pertama kali saya mengenal terminologi Product Owner (PO), saya mengira bahwa Product Owner adalah Klien. Product Owner yang merupakan Pemilik Produk berarti Klien. Tentu saja ini menjadi pertanyaan bagi saya, bagaimana bisa, saya menjadi klien bagi sebuah project yang client based? Cukup membingungkan pada awalnya.

 

Hingga akhirnya saya mencoba mencelupkan tangan saya di beberapa project Labtek Indie, saya menemukan bahwa ternyata role Product Owner bukan lah menjadi Klien. Bukan juga sebagai Project Manager.

 

Lalu pertanyaannya, apa itu PO?

Definisi role Product owner menurut scrum alliance:

  • Resisting the temptation to "manage" the team.

 

  • The team may not self-organize in the way you would expect it to.

 

  • This is especially challenging if some team members request your intervention with issues the team should sort out for itself.

 

  • Resisting the temptation to add more important work after a Sprint is already in progress.

 

  • Being willing to make hard choices during the sprint planning meeting.

 

  • Balancing the interests of competing stakeholders.

Untuk menjadi Product Owner, sama seperti hal-hal praktis lainnya, butuh latihan yang intensif dan ekstensif untuk dapat benar-benar memahami apa peran dan tanggung jawab seorang Product Owner. Pada artikel ini saya akan berbagi pengalaman dan berbagi cerita tentang role Product Owner.

 

Saya lebih nyaman untuk memaparkannya dalam format tahap per tahap, jadi mari kita mulai:

Step 1

PO memiliki tanggung jawab untuk mendampingi klien dalam proses product development. Di perusahaan Labtek Indie, PO tergabung dalam komposisi tim Design Sprint. Ibarat dokter, tim Design sprint memiliki duty untuk melakukan diagnosa terhadap klien, memahami konteks produk, model bisnis, hingga melakukan ideasi untuk membuat solusi terkait pengembangan produk dalam sebuah ‘kitab panduan’ berupa Product Backlog (tentang hal ini nanti akan saya bahas pada bagian step yang lain).

 

Ini merupakan langkah awal dalam membantu klien untuk memunculkan informasi yang valuable ke permukaan, serta menjadi sebuah proses untuk menyetarakan level pemahaman yang ada di pikiran klien dan tim Design Sprint.


Ilustrasi

Seorang klien menyewa jasa tim arsitek dalam membangun rumah. Begini percakapannya:

 

Klien: saya ingin memiliki ruang keluarga yang luas
Design Sprint (DSP) Team: Mengapa bapak ingin memiliki ruang keluarga yang luas besar?
Klien: Karena saya nyaman
DSP Team: Untuk merasa nyaman, mengapa bapak harus memiliki rumah yang besar?
Klien: Hal yang membuat saya nyaman sebenernya ketika saya kumpul bareng cucu-cucu dan keluarga anak-anak saya. Maka dari itu, saya ingin rumah saya cukup menampung mereka jika ada arisan keluarga atau pengajian.

 

Ilustrasi tersebut adalah analogi sebuah proses dalam mengekstrak informasi klien. ‘Saya ingin membangun rumah yang besar’ adalah needs, lalu needs tersebut diubah menjadi sebuah kalimat yang memiliki konteks.

 

“Sebagai Klien, saya ingin memiliki rumah yang besar sehingga saya dapat mengajak keluarga-keluarga saya untuk kumpul bersama di rumah sama”.

 

“As a (client), i need to … so that …”


Kalimat di atas adalah kalimat yang telah memiliki konteks, dalam artian ada user-nya (dalam kasus ini, user-nya dalah klien) dan terdapat hubungan sebab-akibat antar premis.

 

Tugas pertama, PO harus bisa mengekstrak informasi dari klien dan stakeholder lain (jika dibutuhkan) untuk membuat User Stories.

Step 2

Setelah memiliki User Stories, PO menyusun User Stories tersebut menjadi Product Backlog. Product Backlog adalah deliverable yang wajib dibuat oleh PO, karena dokumen ini merupakan kunci bagi keberjalanan project.

 

Bagi PO, Klien dan Product Backlog ini menjadi alat untuk memahami lingkup pekerjaan yang di-tackle oleh Scrum Team. Selain itu, dari sisi Scrum Team, Product Backlog adalah alat untuk menerjemahkan task list yang harus dikerjakan oleh Scrum Development Team.

Step 3

Setelah menjadi Product Backlog (PB), langkah selanjutnya adalah membagi scope pekerjaan dari mulai yang paling krusial hingga yang paling nice to have. Pembagian scope pekerjaan ini kami sebut sebagai Sprint Backlog, dimana User Stories yang tertera di product backlog merupakan User Stories yang sudah terkurasi sesuai dengan Sprint Goal yang ditentukan.

User Stories dalam Product Backlog.

Sprint Goal sendiri adalah target yang ditentukan dalam sebuah sprint, apabila sprint berjalan dengan baik maka Sprint Goal dapat tercapai. Dalam tahap ini pembuatan Sprint Goal dan Sprint Backlog dibuat secara bersamaan.

Sprint Backlog.

Sprint Goal.

Tahap ini adalah tahap dimana kemampuan PO sebagai peran yang mampu membaca visi pengembangan produk diuji. PO harus mampu menyusun prioritas, sesuai dengan lingkupnya. Di lingkup yang high level, PO harus mampu membagi prioritas Sprint sesuai target sehingga mencapai sebuah prototype yang pantas disebut sebagai Most Viable Product (MVP). Di lingkup yang lebih detil, PO juga bertanggung jawab untuk menentukan prioritas User Stories yang dipaparkan dalam sebuah Sprint.

How to Build your MVP.

Level Priority User Stories.

Step 4

Dealing dengan klien adalah hal yang susah-susah gampang. Paradigma umum yang sering dijumpai adalah klien hanya ingin produk jadi, tidak peduli dengan proses yang dijalani oleh penyedia jasa. Proses produksi sebuah produk digital tidak semudah pak Tarno, tinggal menyebut ‘sim salabim jadi apa prok prok prok’ semua masalah beres. Di sinilah tugas PO untuk memberi pengertian tentang proses development, menjelaskan pertimbangan mengapa sprint dibagi dalam scope-scope pekerjaan yang ditentukan.

 

Scrum lebih memprioritaskan time & cost sebagai fixed parameter dalam proses development, dan lebih menjadikan scope pekerjaan sebagai parameter yang dinamis. Scope pekerjaan tentu disesuaikan dengan kapasitas pengerjaan.

 

Mengapa kami lebih memilih menjadikan Scope pekerjaan ini dinamis dibading time & cost? Karena kami ingin quality dapat terjaga dalam waktu yang terhitung dan harga yang fixed. Sprint backlog & output-nya adalah manifestasi dari Scope pekerjaan itu sendiri.

Waterfall vs Agile.

Project deal? Mari lanjut ke langkah berikutnya!

 

Project not deal? Mungkin Anda butuh penyesuaian scope pekerjaan Anda dalam pembuatan Product Backlog.

 

Dalam menentukan ulang scope pekerjaan di Sprint Backlog (SB), selalu telusuri dari hal yang menjadi prioritas. Pertahankan hal yang prioritas, dan pertimbangkan ulang pada bagian-bagian yang kurang prioritas.

Step 5

Project sudah disepakati oleh klien! Sprint sudah secara resmi berjalan. Scrum Master mengagendakan event-event Scrum, dan event krusial bagi PO adalah ketika melakukan Scrum Development Team (SPM). Event ini penting karena hasil akhir dari event ini adalah kesepakatan SB antara PO dan SDT.

 

User Stories dijelaskan sejelas jelasnya oleh PO, SDT berhak mengajukan pertanyaan seputar User Story, dan PO berkewajiban untuk menjelaskan maksud dan tujuan setiap User Story. Jika ada hal yang tidak disepakati bersama antara PO dan SDT, maka boleh melakukan voting atau musyawarah untuk menyelesaikan isu tersebut. Lakukan hal ini hingga mencapai kata mufakat untuk menjalankan Sprint Backlog yang ideal untuk dijalankan.

Step 6

Selama Sprint berjalan, PO harus dapat mengkomunikasikan apa yang terjadi selama proses development (tentu untuk hal2 yang dirasa signifikan) kepada klien. Ada kalanya PO harus siap untuk siap menjawab pertanyaan dari klien terkait proses development.

Step 7

Ketika Sprint sudah selesai, maka saatnya melakukan ritual terakhir dievent scrum, yaitu Sprint Review meeting dan Retrospective Meeting.

 

Sprint Review Meeting adalah event untuk melakukan uji kelayakan bagi User Stories yang sudah disepakati di awal. Pada proses ini setiap User Stories akan disusuri satu per satu untuk diuji melalui lensa PO sebagaiuser, apakah sesuai dengan parameter done yang telah di-set bersama. Semua User Stories akan terlihat secara jelas, mana yang done, mana yang not done.

 

Berbeda dengan Sprint Review Meeting, Retrospective Meeting adalahevent untuk membahas kinerja tim yang terjadi di dalam sprint. Setiap SDT termasuk PO berhak mengomentari antar tim SDT, boleh juga mengomentari diri sendiri terkait performa dalam setiap role yang dipegang. Hal ini bukan ditujukan untuk mencari kambing hitam, siapa yang salah siapa yang benar, dst. Hal ini dilakukan agar di sprintselanjutnya tim dapat bekerja dengan lebih optimal, mengambil hikmah dari apa yang sudah dilalui di Sprint sebelumnya.


Itu dia beberapa pengalaman saya menjadi Product Owner di Labtek Indie, pengalaman yang saya bagikan dalam beberapa tahap sesuai proses yang saya lalui.

 

Yang saya suka dari menjadi Product Owner adalah, kita memilikiprevillege untuk menentukan arah pengembangan produk. Anda menjadi ujung tombak, yang bisa dipakai untuk berburu mencari bahan makan malam Anda atau malah Anda menusuk diri Anda sendiri. Anda yang menentukan.





Bagung Agus

Bagung Agus

Labtek Indie's Workflow Management Manager

One of Labtek Indie's main crew. A designer & soto-freak with interest in interaction between human & environment. Meddling with perfection for every project’s process & documentation.

One of Labtek Indie's main crew. A designer & soto-freak with interest in interaction between human & environment. Meddling with perfection for every project’s process & documentation.

Things you might like

Review

Design Thinking Bersama Indosat

Labtek Indie berkesempatan memberikan workshop di acara Growth Partners: Capability Building 2017 di Gedung Djakarta Theatre bersama tim sales Indosat. Dalam acara ini, Labtek Indie menjadi salah satu fasilitator yang mempresentasikan Design Thinking.

By Ghea Raema | July 24, 2017

Insight

Pentingnya Prototyping dalam Proses Design Thinking

Prototype sendiri adalah tahapan yang ditujukan untuk mentransformasi sifat-sifat abstrak dari sebuah ide menjadi lebih berwujud. Tahapan ini tidak hanya berupa proses visualisasi ide tetapi juga proses pembangunan ide.

By Ghea Raema | July 17, 2017