Document Engineer Hijrah dari Tim Developer ke Tim Produk, Apa Bedanya?
Semenjak awal tahun 2020, saya bergabung dengan tim produk, meski dengan pekerjaan yang sama sebagai Document Engineer (New Year, New Team 🎉🎉🎉).
Ada banyak perubahan yang saya alami, baik dalam komposisi tim, ritme kerja, hingga cakupan tanggung jawab pekerjaan.
Awalnya tim produk terdiri atas:
- 3 Desainer
- 2 Researcher
- 1 Document Engineer
- 1 Lead Developer
- 1 CPO.
Seiring berjalannya waktu tim produk mengalami perubahan komposisi tim menjadi:
- 3 Desainer
- 1 Researcher
- 2 Document Engineer
- 1 Lead Developer
- 1 CPO
Tugas utama dari tim produk adalah menyiapkan semua kebutuhan tim developer, sesuai dengan keinginan stakeholder. Bisa dikatakan tim produk berfungsi sebagai middleman (atau middlewoman karena tidak semua orang di tim produk adalah pria, hee). Menurut saya, pekerjaan sebagai jembatan penghubung yang kami lakukan di tim produk bukanlah sesuatu yang mudah, meski tidak terlalu sulit juga.
Lalu apa tugas saya sebagai Document Engineer di tim produk? Awalnya saya juga bingung kontribusi seperti apa yang bisa saya berikan untuk tim ini. Tim produk ternyata tidak membutuhkan pembuatan Diagram UML (Unified Modeling Language), dokumentasi database, atau dokumentasi API yang biasa saya kerjakan.
Ternyata, pekerjaan yang harus saya lakukan adalah sebagai berikut:
- Membuat diagram flow end-to-end dari fitur yang ada saat ini sampai fitur yang sedang dikembangkan
- Membuat diagram flow end-to-end dari proses bisnis yang dilakukan
- Membuat diagram flow dari masing-masing bisnis prosess
- Membuat pemetaan fitur
- Terkadang ikut mengumpulkan informasi fitur yang akan dikembangkan
- Membuat Product Requirement Document (PRD)
- Membuat dokumentasi kanban
Sebagai informasi, sebelum mengirimkan kebutuhan produk kepada tim developer, kami sebagai tim produk biasanya akan melakukan hal-hal berikut:
1. Menerima Roadmap
Roadmap merupakan hal yang krusial bagi tim produk. Mengapa demikian? Karena Roadmap merupakan pedoman untuk memahami tujuan yang diinginkan stakeholder.
2. Mapping dan mencari korelasi dari fitur yang sudah ada dengan fitur yang akan dikembangkan
Hal ini perlu dilakukan demi mengetahui “benang merah” dari setiap fitur, baik fitur yang sudah ada maupun fitur baru. Hal ini juga akan mempermudah tim produk dalam melakukan penelusuran apabila ada fitur yang sebelumnya perlu diperbaiki, serta menemukan input dan output yang saling berkaitan antar fitur. Hal ini menjadi semakin penting bila ada anggota tim baru yang tidak terlibat pengembangan sistem sejak awal.
3. Memenuhi kebutuhan fitur dari stakeholder
Para stakeholder tentu membutuhkan beberapa fitur tertentu agar tujuan mereka saat membuat sebuah sistem bisa terwujud. Harapan inilah yang perlu ditangkap oleh tim produk, untuk selanjutnya dicarikan jalan keluar.
4. Definisikan Masalah
Sebuah kebutuhan itu muncul karena adanya masalah atau proses yang tidak efektif. Hal-hal tersebut harus kita gali, pahami, dan dibagi menjadi beberapa bagian kecil, agar bisa dijabarkan dan dirincikan permasalahan seperti apa yang bisa diatasi.
5. Menyelesaikan Masalah
Dari masalah-masalah yang sudah dirincikan, kita dapat mencari solusi yang tepat. Saat menyelesaikan suatu masalah, kita biasanya akan mencari beberapa ide sampai menemukan user journey yang ideal.
6. Validasi ke Stakeholder
Hal ini sangat penting, guna mengetahui apakah apa yang ditangkap oleh tim produk sudah sesuai dengan kebutuhan stakeholder. Jika sudah sesuai, maka keputusan final bisa dibuat.
7. Pembuatan Desain
Karena waktu yang sedikit, biasanya desain dibuat sembari mencari penyelesaian masalah. Ketika melakukan validasi ke stakeholder, desain tersebut harus sudah dalam bentuk high fidelity design.
8. Pembuatan PRD (Product Requirement Document)
PRD merupakan dokumen yang bisa dijadikan acuan oleh developer, berisi gambaran fitur yang akan mereka kembangkan secara lengkap, baik dari sisi journey maupun desain.
Keberadaan PRD ini mungkin membuat proses yang ada seperti menggunakan metodologi Waterfall. Namun, PRD juga bisa digunakan pada metodologi Agile, bisa mempersingkat waktu perencanaan karena sudah ada gambaran alur dan desainnya. Saat perencanaan, dokumen ini masih bisa diubah sesuai kebutuhan developer asal tidak mengubah proses bisnis yang telah didefinisikan.
Melihat poin-poin di atas, banyak sekali hal baru yang saya rasakan. Hal tersebut tentunya sangat berbeda dengan apa yang pernah saya lakukan di tim developer. Hal ini pun mendorong saya untuk terus mempelajari hal baru setiap saat.
“Setiap hari belajar hal baru”, ujar seorang Codex Rangers.
