Pada kesempatan kali ini, saya akan menuliskan salah satu permasalahan dalam proses pengembangan proyek/produk digital, yakni perihal dokumentasi.
Selama ini tim development melakukan pembuatan proyek/produk sesuai permintaan, baik permintaan yang harus selesai dengan waktu yang wajar hingga tak masuk akal.
Banyaknya proyek yang harus dikerjakan dengan proses pengembangan dan dokumentasi yang tidak cukup baik akan membuat produk yang sudah jadi cenderung tidak jelas rencana development-nya.
Pembuatan dokumentasi bisa menjadi budaya dalam menata proyek/produk yang sudah ada menjadi lebih rapi. Sehingga jika ada permintaan produk yang mirip dengan yang sudah ada, tinggal menggunakan yang sudah ada.
Project/Product Document Requirement merupakan salah satu fondasi keberhasilan suatu proses project/product development.
Document Requirement mendefinisikan spesifikasi dari proyek/produk yang akan dikembangkan, lengkap dengan gambaran fitur yang diharapkan. Dokumen ini biasanya digunakan oleh tim development, client, atau pihak lain yang terlibat untuk memahami dan memenuhi kebutuhan development.
Penulisan document requirement yang tidak didefinisikan dengan jelas dan tidak ditulis dengan buruk akan mengakibatkan perubahan atau penambahan fungsionalitas yang jauh dari requirement awal. Sehingga hal tersebut dapat mempengaruhi waktu dan biaya dari development.
Siapa yang membuat Document Requirement?
Pembuatan Document Requirement ini biasa dilakukan oleh seorang Document Engineer, namun dibeberapa perusahaan pembuatan dokumen ini juga bisa dilakukan oleh seorang Technical Writer atau System Analyst.
Document Engineer merupakan salah satu job role dalam dunia digital dan tidak sedikit yang masih belum mengetahui sosok Document Engineer ini. Karena pekerjaan sebagai Document Engineer masih kalah tren dibandingkan dengan Backend Developer, Frontend Developer, UI Designer, UX Researcher, atau QA Engineer.
Beberapa jobdesc dari seorang Document Engineer sudah ada di beberapa perusahaan digital, seperti perencanaan journey yang biasa dilakukan oleh System Analyst serta pembuatan dokumentasi tentang bagaimana sebuah produk digital dibuat dan dibuat yang biasanya dilakukan oleh Technical Writer.
Aktor penting dalam proses development sebuah project atau digital product ?
Kita bahas sedikit mengenai siapa saja aktor-aktor yang berperan di belakang pengembangan sebuah proyek/produk. Dan aktor di balik pengembangan ini bisa saja berbeda-beda untuk setiap perusahaan, tergantung kebutuhan dari perusahaan tersebut.
Berikut beberapa aktor yang sering terlibat dalam pengembangan sebuah proyek/produk:
1. UX Researcher
UX Researcher adalah peneliti yang mencari tahu segala hal tentang pengguna (user), baik keinginan maupun kebutuhannya. Ia akan melakukan riset tentang tingkah laku para pengguna saat menggunakan sebuah produk. Tujuannya adalah untuk membantu dan memberikan masukan kepada para desainer.
2. UI Designer
UI Designer bertugas merancang antarmuka yang nantinya akan digunakan oleh pengguna untuk berinteraksi dengan suatu sistem, perangkat, atau aplikasi.
3. Frontend Developer
Salah satu tanggung jawabnya adalah menerjemahkan (slicing) sebuah desain menjadi tampilan situs, serta membuatnya menjadi interaktif dan dinamis sesuai kebutuhan.
4. Backend Developer
Backend Developer berperan sebagai penghubung antara desain dengan data yang akan disajikan sebagai sebuah informasi. Beberapa tanggung jawab yang dimiliki oleh Backend Developer diantaranya mengintegrasikan API; membuat testing API untuk melihat apakah performa API sudah baik; merancang struktur model data; memastikan struktur kode yang dibuat sudah aman.
5. Software Quality Assurance Engineer
Quality Assurance disini bertugas untuk menjaga kualitas dari sebuah proyek/produk. Mereka melakukannya dengan berbagai macam tes diantaranya, Blackbox test; Whitebox test; Greybox test; Regresi test; Smoke test. Tanggung jawab seorang QA tidak hanya memberitahu nama fitur yang terdapat bugs tetapi juga:
- Menganalisis penyebab bugs.
- Menjelaskan langkah-langkah bagaimana bugs tersebut ditemukan.
- Menjelaskan bagaimana alur yang diharapkan berdasarkan Acceptance Criteria.
- Memeriksa dan memastikan dari sisi teknis apakah bugs tersebut berasal dan harus diselesaikan oleh tim frontend atua backend.
- Memeriksa dan memastikan apakah bugs tersebut berpengaruh ke fitur lain atau tidak.
6. Software Documentation Engineer
Tugas dari Document Engineer adalah membuat dokumentasi blueprint dari sebuah aplikasi yang sedang dikembangkan, agar dapat dimengerti oleh orang awam.
Berkenalan dengan Document Engineer
Menurut Robert J. Glushko dan Tim McGrath di dalam bukunya Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services, Document Engineer bertugas menggambarkan, menganalisis, merancang, dan mendiskusikan teknik serta arsitektur yang nantinya akan menjadi panduan untuk proses development aplikasi.
📑️Mengapa harus ada dokumentasi dalam proses project/product development?
Bagi tim yang menerapkan budaya Agile pasti akan membantah statement ini berdasarkan nilai yang ditawarkan Agile yakni, Working Software Over Comprehensive Documentation. Dimana nilai tersebut mengajarkan bahwa membuat produk dan mengirimkannya kepada stakeholder secara cepat lebih diutamakan daripada kegiatan yang berhubungan dengan dokumen.
Lalu apakah dokumentasi tidak lagi penting dalam proses development?
Adanya dokumentasi dalam proses development memudahkan semua pihak yang terlibat dalam proses tersebut dalam mengakses pengetahuan mengenai aplikasi yang sedang dikembangkan tanpa harus bertanya secara langsung kepada developer mengenai fitur, flow, dan arsitekturnya.
Selain itu, dokumentasi yang baik juga dapat memudahkan proses iterasi ketika development dilakukan atau dipindah tangankan kepada orang yang berbeda.
Selain itu, dokumentasi ini penting untuk mendefinisikan dan mendokumentasikan apa saja kebutuhan serta journey yang diinginkan PO (Product Owner) serta stakeholder lainnya. Dengan begitu, data dan journey yang didokumentasikan tersebut nantinya bisa digunakan oleh para developer.
📒 Jadi sebenarnya apa yang dilakukan oleh Document Engineer dalam sebuah tim?
Kenapa harus Tim Scrum?
Scrum merupakan metode implementasi produk yang menggunakan prinsip-prinsip pendekatan agile yang saat ini paling sering digunakan untuk kompleks project. Kerangka kerja scrum ini lebih banyak digunakan untuk project yang kompleks dengan perubahan pasar yang cepat karena sifatnya yang adaptif dengan perubahan sehingga bisa menyesuaikan apabila ada requirement yang perlu ditambahkan.
Dalam sebuah tim yang menerapkan budaya Agile….
Seorang Document Engineer memiliki beberapa tupoksi mulai dari membuat dokumentasi proses pengembangan produk hingga dokumentasi dari produk itu sendiri.
Berikut skenario ketika akan memulai proses development terhadap pekerjaan/proyek baru dan posisi seorang Document Engineer dalam sebuah tim:
- Seorang Document Engineer harus bergabung sejak awal pengembangan proyek, bukan di tengah atau bahkan di akhir proyek.
- Document Engineer harus mengikuti semua proses perencanaan kebutuhan proyek bersama para stakeholder. Proses ini sangat penting, karena dengan begitu Document Engineer dapat memahami proses bisnis dalam pengembangan sebuah aplikasi.
- Setelah memahami proses bisnis, Document Engineer akan menjabarkannya menjadi sebuah flow, use case, dan data yang dibutuhkan sehingga dapat membantu para developer.
- Selanjutnya Document Engineer bisa berdiskusi dengan seluruh anggota tim untuk mendefinisikan hal teknis dan non-teknis terkait aplikasi yang akan dikembangkan sehingga anggota tim akan memiliki pemikiran yang sama mengenai produk yang akan dikembangkan.
- Kemudian sprint dimulai… Semua anggota tim mengerjakan apa yang sudah menjadi kesepakatan berdasarkan posisi masing-masing.
Sprint adalah proses pembuatan produk sampai dapat digunakan dan berpotensi untuk dirilis dengan batasan waktu tertentu.
Yang dikerjakan oleh Document Eengineer….
Sekali lagi!, dokumen yang dibuat oleh seorang Document Engineer akan berbeda tergantung dari budaya kerja dan kebutuhan perusahaannya.
Beberapa dokumen yang dibuat oleh Document Engineer:
- Gathering Requirement: Dokumen ini mencakup semua informasi yang diperoleh selama proses pengumpulan kebutuhan proyek, termasuk kebutuhan bisnis, fungsionalitas yang diharapkan, dan preferensi pengguna.
- System Requirement: Menyajikan persyaratan teknis dan fungsional sistem yang akan dikembangkan.
- Use Case: Dokumen ini menggambarkan interaksi antara sistem dan pengguna melalui skenario yang terstruktur, membantu dalam memahami fungsionalitas sistem dari perspektif pengguna.
- Activity Diagram: Diagram ini menggambarkan alur kerja proses atau aktivitas dalam sistem, membantu dalam pemahaman visual tentang bagaimana sistem beroperasi.
- User Guide: Dokumen panduan yang memberikan informasi kepada pengguna akhir tentang cara menggunakan aplikasi atau sistem.
- Report Scrum Event: seperti laporan stand up, hasil review dan retrospective.
Penjelasan lebih lengkap tentang apa saja yang bisa dilakukan oleh seorang Document Engineer bisa dilihat di artikel ini.
📑 Menyusun Document Requirement yang efektif
Disclaimer❗❗ : Sebenarnya tidak ada susunan baku dalam pembuatan document requirement. Karena setiap perusahaan mempunyai format khusus yang disesuaikan dengan kebutuhan mereka masing-masing.
Document requirement memiliki beberapa fungsi (menurut Silicon Valley Product Group):
- Menjelaskan tujuan produk.
- Sebagai alat komunikasi untuk stakeholder.
- Menjelaskan rincian dari fitur, baik dari sisi fungsional maupun behaviour.
- Membantu developer memahami experience seperti apa yang harus dibuat.
- Membantu tim Quality Assurance memahami fitur yang perlu mereka uji.
❌📑️ Kesalahan yang sering terjadi ketika menyusun Product/Project Document Requirement
Document requirement merupakan dokumen bersama yang mendetailkan apa yang perlu dilakukan untuk mewujudkan produk atau fitur. Daripada menggambarkan bagaimana anggota tim menyelesaikan setiap tugas dalam sebuah sebuah proyek, document requirement dapat digunakan sebagai panduan dan referensi tentang apa yang harus diselesaikan untuk mencapai tujuan proyek yang telah ditentukan.
Namun dalam penulisan atau penyusunan document requirement ada beberapa kesalahan yang sering dilakukan, diantaranya adalah sebagai berikut:
- Penulisan requirement yang tidak lengkap sehingga tidak menggambarkan fitur serta fungsionalitas dari aplikasi yang akan dikembangkan dengan jelas dan terinci.
- Tidak menyusun document requirement secara terstruktur dengan penjelasan dan istilah yang mudah dipahami. Masih menggunakan gaya bahasa yang ambigu.
- Tidak melakukan validasi document requirement sehingga menghasilkan produk/aplikasi yang tidak selaras dengan strategi produk/bisnis secara keseluruhan serta tidak sesuai dengan kebutuhan user.
Akibat dari kesalahan dalam menyusun document requirement adalah ketidaksesuaian antara harapan ekspektasi dan hasil implementasinya. Hal tersebut dapat menurunkan kualitas produk dan meningkatkan risiko kegagalan produk di market nantinya. Dan fase proses development pun akan memakan waktu yang lebih lama serta biaya yang membengkak.
✅📑️ Kriteria dasar yang bisa dijadikan acuan dalam menyusun Document Requirement yang efektif
Untuk menghindari terjadinya kesalahan dalam penyusunan document requirement, ada beberapa kriteria dasar yang bisa kita ikuti dalam menulis document requirement project yang efektif:
✅ 1. Pahami masalah dan kebutuhan client
Memahami masalah dan kebutuhan client menjadi poin penting dalam penyusunan document requirement karena hal ini memudahkan seorang document engineer untuk mengidentifikasi kebutuhan fungsional maupun non-fungsional serta mendefinisikan fitur dan fungsionalitas yang diperlukan oleh aplikasi yang akan dikembangkan.
✅ 2. Tulis dengan jelas, spesifik, konsisten
Setiap requirement harus diungkapkan dengan cara yang mudah dimengerti oleh semua stakeholder yang terlibat. Requirement juga harus ditulis secara spesifik sehingga stakeholder terutama developer memiliki pandangan yang jelas dan pemahaman yang seragam mengenai apa yang dibutuhkan serta apa yang perlu dicapai.
Berikut adalah beberapa tips untuk memastikan bahwa penulisan document requirement kita konsisten dan tidak ambigu:
- Istilah yang digunakan harus konsisten. Contohnya, jika kita pakai button dengan kata “Daftar Sekarang” di satu bagian, jangan tiba-tiba menjadi “Register Now” di bagian selanjutnya.
- Hindari menggunakan singkatan atau istilah yang jarang dipakai atau kurang umum.
- Pertahankan konsistensi dalam gaya penulisan, baik dalam penggunaan tata bahasa maupun struktur kalimat.
- Buat glosarium yang menjelaskan setiap istilah atau singkatan yang mungkin kurang umum agar semua stakeholder memiliki pemahaman yang seragam.
- Pastikan requirement yang kita tulis juga harus menyampaikan seluruh tujuan, ruang lingkup dan kebutuhan project dengan jelas dan tepat.
✅ 3. Lakukan validasi secara berkala
Lakukan validasi untuk memastikan bahwa document requirement jelas dan dipahami oleh semua pihak yang terlibat dalam pengembangan produk. Pastikan semua pihak terlibat memahami dan setuju dengan requirement yang telah ditetapkan.
Validasi berfungsi untuk memastikan bahwa document requirement selalu akurat dan mencerminkan kebutuhan proyek yang sebenarnya. Juga dapat membantu mengidentifikasi masalah dan meningkatkan kualitas produk serta meminimalkan risiko kegagalan produk ketika diluncurkan.
🧩📑️ Komponen penting dalam Document Requirement
Komponen document requirement ini akan berbeda di tempat atau dalam kondisi yang berbeda, karena menyesuaikan dengan kebutuhan bisnis, kondisi budaya, dan tim dalam perusahaan yang mengembangkan.
Namun, sebagian besar document requirement mencakup komponen berikut:
- Product Overview & Background
- Goals & Objectives
- Functional Requirements
- Design Elementss
- Release Criteria
- Timeline
Disclaimer❗❗ : Tidak semua komponen di atas perlu dimasukan ke dalam document requirement, kita hanya perlu mengambil komponen yang relevan dengan proses pengembangan produk/aplikasi yang akan kita kembangkan.
🧩 1. Product Overview & Background
Bagian ini memberikan penjelasan singkat tentang produk termasuk nama produk, stakeholder, status, dan perkiraan tanggal launching. Bagian ini juga menjelaskan mengenai latar belakang dan alasan pembuatan produk.
🧩 2. Goals & Objectives
Bagian ini menjelaskan alasan mengapa document requirement dibuat. Jelaskan apa tujuan kita mengembangkan produk tersebut dan masalah apa yang ingin kita selesaikan.
Masalah apa yang dipecahkan oleh produk ini?
Siapa yang akan menggunakan produk ini?
Mengapa (pengembangan produk) ini penting?
🧩 3. Functional Requirements
Bagian ini memberikan penjelasan mengenai daftar fitur produk yang perlu dikembangkan untuk memenuhi kebutuhan pengguna/stakeholder. Untuk setiap daftar fitur tersebut harus didukung oleh deskripsi, user story, dan use case.
User story merupakan ekspektasi user terhadap fungsionalitas, kinerja, dan kualitas produk yang dikembangkan. User story dapat meghasilkan fitur-fitur yang harus dimiliki oleh aplikasi/produk yang akan dikembangkan.
🧩 4. Design Elements
Pada bagian design elements ini menyertakan UX Flow, UI Design, dan arsitektur dari aplikasi yang akan dikembangkan. Pada bagian ini harus bisa memberikan gambaran yang jelas kepada stakeholder tentang alur pengguna utama dalam produk.
🧩 5. Release Criteria
Bagian release criteria berisikan kriteria yang harus dipenuhi oleh produk sebelum dirilis untuk pengujian beta. Kriteria tersebut dapat mencakup hal-hal seperti:
- Functionality → memastikan semua fitur dan fungsionalitas yang dijanjikan telah diimplementasikan dan juga sesuai dengan spesifikasi. Serta memastikan produk mudah digunakan dan memberikan hasil yang diharapkan.
- Reliability → memastikan produk dapat menangani kesalahan tanpa menyebabkan kegagalan sistem secara keseluruhan. Serta memastikan produk dapat pulih dari kegagalan sistem tanpa kehilangan data yang signifikan.
- Performance → memastikan bahwa produk memberikan respons yang cepat dan efisien terhadap input user dan memenuhi persyaratan kinerja yang diinginkan.
🧩 6. Timeline
Bagian timeline memberikan perkiraan kasar mengenai apa yang harus dikirimkan dan kapan akan dikirimkan kepada stakeholder terkait.
Pada bagian ini, kita tidak perlu terlalu spesifik dengan tanggal dan tenggat waktu. Cukup menentukan berapa lama waktu yang dibutuhkan untuk fase pengembangan tertentu.
🕹️ Conclusion
Banyak yang menganggap bahwa penyusunan document requirement ini erat kaitannya dengan metodologi Waterfall karena semua requirement dan kebutuhan ditentukan secara rinci di fase pertama pengembangan proyek/produk.
Namun dalam beberapa tahun terakhir, banyak organisasi yang berubah ke arah pengembangan yang lebih adaptif. Karena itu, sebuah document requirement menjadi sebuah kebutuhan.
Tujuan pembuatan document requirement adalah membuat semua pihak bisa selaras dalam memahami cara kerja produk dan fitur yang dibuat, serta mengurangi kesalahpahaman dan ketidakcocokan antara kebutuhan client dan produk yang dihasilkan. Namun dokumen tersebut masih bisa diubah sesuai kebutuhan, asal tidak mengubah proses dan tujuan bisnis yang telah didefinisikan sebelumnya.
Selalu tulis document requirement produk terlebih dahulu…
Karena dokumen ini yang akan dipatuhi oleh tim selama proses pengembangan. Hal ini seharusnya membuat segalanya lebih mudah bagi semua stakeholder, bukan membuat mereka menjadi terlalu rumit.
Jaga agar dokumentasi ini tetap singkat namun informatif sehingga semua orang yang terlibat dapat menggunakannya sebagai acuan referensi kapan pun mereka membutuhkannya.
Membutuhkan bantuan dalam pengembangan sistem informasi dan aplikasi untuk bisnis?. Arkatama sebagai Jasa Konsultan IT dan Software House dapat membantu bisnis dalam merancang, mengembangkan, dan implementasi solusi IT yang sesuai dengan kebutuhan, termasuk memberikan tampilan UI/UX yang baik.
Jangan ragu untuk melakukan diskusi dan bertanya tentang detail proses kerja yang tim kami lakukan. Arkatama juga berpengalaman menjadi IT Training Center dengan menyediakan layanan pelatihan IT untuk mencetak sumber daya manusia yang kompeten pada era transformasi digital saat ini. Hubungi tim kami disini!
Ingin bertanya atau mempunyai masukan serta tambahan terkait tulisan ini?
Silahkan ketik pertanyaan, masukan dan tambahan tersebut di Bagian Response di bawah.
Terima kasih telah meluangkan waktu untuk membaca.. 😊
