Bagaimana dokumentasi mengubah pengembangan produk – Beragampengetahuan

Ketika, pada pertemuan berikutnya, klien harus mengingatkan pengembang lagi untuk tidak merusak apa pun, mungkin inilah saatnya untuk melihat proyek secara lebih luas. Dalam hal ini, logis untuk mengangkat masalah penggantian pengembang ini atau mencari tahu apa yang menyebabkan situasi ini, namun kenyataannya semuanya mungkin berbeda.

Jadi sepertinya proyek tersebut dikelola oleh pengembang, bukan klien. Seolah-olah klien bergantung pada mereka dan pada saat yang sama membayar untuk proses pengembangan. Ternyata ini adalah kasus kebingungan peran, atau “pelanggan di cermin”.

Mengapa ini terjadi dan bagaimana cara memperbaikinya? Oke, mari kita luruskan ini.

“Saya harap tidak akan ada masalah kali ini”

Situasi di mana pelanggan tetap memiliki ekspektasi terhadap pengembang meskipun terjadi insiden biasanya terjadi karena alasan berikut:

• Mungkin pakar tersebut memiliki pengetahuan atau keterampilan unik yang sulit digantikan, dan klien harus hidup dengan kesalahan;
• Atau, proyek tersebut kekurangan dokumentasi, sehingga menyulitkan semua pihak yang terlibat untuk memahami tugas tersebut.

Sesuai dengan standar manajemen proyek, dalam hal ini status proyek saat ini akan dianalisis untuk mengidentifikasi permasalahan utama. Proses pengembangan juga akan ditinjau, dokumentasi yang hilang akan dikumpulkan, dan pelatihan tambahan akan diberikan kepada tim. Hal ini juga berguna untuk mendiskusikan harapan dan persyaratan dengan klien untuk memastikan bahwa semua pihak memahami tujuan dan sasaran proyek.

Jika, terlepas dari semua upaya, masalah tetap ada, maka muncul pertanyaan tentang penggantian spesialis tertentu atau bahkan seluruh tim. Pada akhirnya, sebuah proyek yang sukses membutuhkan kerja yang terkoordinasi dengan baik serta saling pengertian dan kepercayaan di antara semua peserta.

Namun kenyataannya, sebuah proyek kekurangan dokumentasi karena ingin menghemat sumber daya. Sayangnya, sangat mudah untuk terjebak dalam “cermin” seperti itu jika Anda mengurangi waktu, tenaga, dan sumber daya yang Anda habiskan untuk menentukan dan mendokumentasikan persyaratan yang harus dipenuhi produk Anda untuk mencapai tujuan bisnis Anda. Biasanya, persyaratan ini dapat dinyatakan dalam lingkup pekerjaan, Spesifikasi Persyaratan Perangkat Lunak (SRS), dan/atau Spesifikasi Produk (SPEC).

Tanpa perhatian yang tepat terhadap dokumen-dokumen ini, proyek berisiko menghadapi banyak masalah seperti Komunikasi yang buruk antara semua peserta, tenggat waktu yang terlewatDan Pembengkakan anggaranMeningkatkan. Jadi, mari kita cari tahu nilai dari dokumen-dokumen ini dan apakah proyek memerlukannya.

Apakah dokumentasinya tidak ada gunanya, atau hanya sesuatu yang tidak Anda lihat di permukaan?

Biasanya, sebelum suatu produk dirilis pertama kali, Dokumentasi tidak ada nilainya. Mengompilasi dan mendukungnya memerlukan waktu dan sumber daya, dan pada awalnya yang perlu Anda lakukan hanyalah mengembangkan fitur-fitur baru dan mengeluarkan produk secepat mungkin – tidak ada waktu untuk menulis dokumentasi. Namun, seiring berjalannya waktu, semakin banyak situasi yang muncul ketika perubahan pada satu bagian kode sumber produk menyebabkan bug di bagian lain.

Hal ini menyebabkan tim menghabiskan lebih banyak waktu untuk memperbaiki bug dan pemecahan masalah ini daripada mengembangkan fitur baru. Dalam hal ini, jelas bahwa kurangnya dokumentasi dapat memperlambat proses pengembangan secara signifikan dan menurunkan kualitas produk. Ketika suatu proyek mencapai tingkat kompleksitas tertentu, dokumentasi menjadi alat yang sangat diperlukan.

Skenario 1. Komponen perangkat lunak harus diubah, namun cara kerjanya tidak didokumentasikan

Misalkan suatu komponen telah di-tweak beberapa kali, namun sudah lama sekali sehingga sulit mengingat detailnya. Pengembang memeriksa kode aplikasi dan mencoba memahami cara kerja fungsi tertentu. Tanpa dokumentasi, mereka harus menghabiskan banyak waktu untuk mempelajari kode untuk mencoba memahami detailnya.

Oleh karena itu, para ahli mulai menyempurnakan komponen ini berdasarkan kesimpulan pribadi mereka. Setelah melakukan uji asap, pengembang membagikan hasilnya kepada klien untuk verifikasi dan validasi. Tanpa memahami semua seluk-beluknya, pelanggan dengan cepat menemukan bahwa semuanya berfungsi sebagaimana mestinya dan oleh karena itu menyetujui perubahan untuk dirilis. Pada saat yang sama, baik pengembang maupun pelanggan sendiri tidak ingin terjadi kesalahan, juga tidak ingin perubahan mempengaruhi fungsi lain yang terkait dengan komponen.

Namun kesalahan terjadi karena kurangnya dokumentasi, pemahaman interaksi komponen produk, dan pengujian integrasi. Pada akhirnya, mempelajari bug semacam itu hanya mungkin dilakukan jika pengguna memperhatikan dan melaporkannya.

kekurangan:

Kurangnya dokumentasi memperlambat proses pengembangan dan meningkatkan kemungkinan kesalahan.

Skenario 2. Pengguna melaporkan bug dan meminta perbaikan

Mari kita bayangkan sebuah skenario di mana pengguna menemukan bug dalam suatu aplikasi dan melaporkannya melalui sistem dukungan pelanggan. Setelah pemberitahuan kesalahan diterima dan dianalisis, pelanggan memberikan tugas kepada pengembang untuk menghilangkan masalah yang teridentifikasi dan memperbarui produk.

Analisisnya dapat menarik kesimpulan sebagai berikut:

• Perilaku sistem memadai

Pengembang mulai mempelajari kode sumber dan menemukan bahwa perilaku sistem yang dilaporkan oleh pengguna telah diketahui dan diharapkan. Ada komentar di kode yang menjelaskan mengapa sistem bekerja seperti itu.

Namun keluhan pengguna tidak bisa diabaikan begitu saja karena akan mempengaruhi kepuasan mereka terhadap produk. Dalam hal ini, pengembang dan pelanggan memutuskan untuk mencatat “bug” yang ditemukan sebagai “perbaikan”. Ini berarti bahwa perilaku sistem akan berubah di masa depan agar lebih memenuhi harapan pengguna.

Oleh karena itu, pelanggan dan pengembang menemukan diri mereka dalam situasi yang dijelaskan dalam contoh pertama, di mana perubahan perlu dilakukan pada komponen perangkat lunak tanpa dokumentasi lengkap.

Pengembang mulai mengerjakan kode dan mencari bantuan dari rekan kerja yang memahami fungsi komponen perangkat lunak yang diinginkan. Adakan pertemuan untuk membahas kemungkinan penyebab dan cara memperbaiki kesalahan.

Hasilnya, bug tersebut diketahui dan pengembang mulai memperbaikinya. Namun tanpa dokumentasi yang lengkap, proses perbaikan menjadi sulit karena perubahan di satu tempat dapat menimbulkan masalah yang tidak terduga di bagian lain sistem. Oleh karena itu, tim kembali ke skenario 1, dimana perubahan yang dilakukan dapat mempengaruhi komponen terkait lainnya sehingga memerlukan pengujian dan revisi tambahan.

kekurangan:

Tanpa dokumentasi yang lengkap, proses perbaikan dan/atau penyempurnaan akan sulit dilakukan sehingga memerlukan revisi dan pembahasan tambahan.

Baca juga Earned Value Management (EVM): Bagaimana memprediksi hasil proyek dan kapan EVM membantu?

Skenario 3: Jumlah pengguna meningkat sehingga memerlukan optimasi perangkat lunak

Mari kita asumsikan semakin banyak pengguna yang mulai menggunakan aplikasi dan bebannya bertambah. Tim memutuskan untuk menganalisis kinerja sistem saat ini dan membuat perubahan arsitektur untuk mendukung pertumbuhan pengguna lebih lanjut. Namun, tidak ada yang mengingat semua detail penerapan fitur tersebut karena dokumentasinya hilang atau kedaluwarsa.

Tanpa dokumentasi yang diperlukan tentang komponen, tidak mungkin untuk memperhitungkan seluruh fungsi perangkat lunak. Oleh karena itu, karena ketidakhadirannya, proses pengujian setelah perubahan arsitektur tidak akan lengkap. Oleh karena itu, beberapa bug akan tetap ada pada tahap penerbitan perubahan, yang juga akan mempengaruhi pengoperasian aplikasi dan kinerjanya.

kekurangan:

Tanpa dokumentasi, proses optimasi perangkat lunak menjadi lebih kompleks dan berbahaya karena pengembang tidak memiliki pemahaman yang lengkap tentang cara kerja sistem.

Baca juga Penulisan Ulang Kode vs. Pemfaktoran Ulang Kode. Pilih strategi transcoding terbaik

Apa yang harus diketahui pelanggan

Tanpa dokumentasi (lingkup pekerjaan, SRS, SPEC), sumber informasi terpercaya tentang keseluruhan produk, menjelaskan semuanya secara keseluruhan dan menjelaskan setiap fitur secara individual, pelanggan dan tim proyek terpaksa mengandalkan ingatan dan kode sumber produk mereka. Selain itu, karena hanya pengembang yang mengetahui kode sumbernya, hanya merekalah yang dapat memahami cara kerja produk sebenarnya. Oleh karena itu, pakar inilah yang menjadi andalan utama produk, kepuasan pengguna, dan kesejahteraan pelanggan. Oleh karena itu, pelanggan menjadi bergantung pada pengembang yang menciptakan semua bug yang menimbulkan ketidakpuasan di antara pengguna dan pelanggan itu sendiri.

Salah satu langkah salah yang terkadang dilakukan pelanggan ketika mereka berada dalam situasi ini adalah mengganti pengembang. Pelanggan mungkin mendapat kesan bahwa para ahli saat ini tidak memiliki pengetahuan yang diperlukan tentang produk atau telah kehilangan antusiasme mereka sebelumnya. Oleh karena itu, mereka berasumsi bahwa profesional lain dapat membuat perangkat lunak lebih baik dan memiliki lebih sedikit bug. Keputusan ini memperburuk situasi.

Jika pengembang saat ini memiliki sebagian pengetahuan tentang proyek dan akrab dengan pengoperasian komponen perangkat lunak, maka akan memerlukan waktu bagi para ahli baru untuk memahami kompleksitasnya. Mereka hanya akan mengandalkan apa yang mereka lihat saat ini di kode sumber produk.

Dalam hal ini, pakar baru harus menghabiskan beberapa bulan untuk mempelajari kode dan menemukan bug baru hingga pengetahuan mereka tentang produk mencapai tingkat yang sama dengan pengembang sebelumnya. Saat pelanggan dengan sabar menunggu hari ketika pakar baru memperoleh pengetahuan produk yang lengkap, perusahaan berisiko kehilangan pengguna aplikasi dan pendapatan.

Vitaly Hornik

COO, Ph.D. Magister IT (Ilmu Komputer), PMP

Semakin lama masa pakai produk, semakin tinggi persyaratan dokumentasinya.

Penting untuk memahami hal ini Kurangnya dokumentasi berkualitas tinggi tidak hanya memperburuk permasalahan yang ada saat ini namun juga menciptakan permasalahan baru. Dokumen tersebut adalah a merupakan bagian integral Mencakup seluruh proses pengembangan dan pemeliharaan produk. Ini membantu menghindari potensi masalah dengan memberikan kejelasan dan pemahaman tentang semua aspek proyek, yang pada akhirnya menghasilkan produk yang lebih stabil dan berkualitas tinggi.

Ketika persyaratan dan proses tidak didokumentasikan dengan benar, ketergantungan pada masing-masing anggota tim akan tercipta dan proyek berada pada risiko yang serius. Oleh karena itu, dokumentasi harus mudah diakses dan diperbarui secara berkala.

Baca juga Seni Rumit dalam Memaksimalkan Nilai. Bagaimana membuat setiap koin berarti

sebagai kesimpulan

Dokumentasi tidak ada nilainyaitu tak ternilai harganya. Ini adalah bagian dari keseluruhan proses pengembangan dan memastikan umur panjang produk Anda. Tanpa dokumentasi berkualitas tinggi, berinvestasi besar-besaran dalam pengembangan produk, menjalankan kampanye iklan yang mahal, dan menguasai sebagian pasar mungkin tidak akan memberikan hasil yang diinginkan, karena pengembangan fitur dan perbaikan produk baru memerlukan waktu lama. Jika Anda tidak mengubah sikap terhadap dokumentasi, Anda akan kehilangan loyalitas pengguna dan menempatkan proyek Anda pada risiko yang signifikan.

Jika Anda familiar dengan skenario di atas pada proyek Anda saat ini, mungkin belum terlambat untuk mulai membuat dokumentasi?

Hubungi kami dan kami akan dengan senang hati mengembangkan produk yang diperlukan dan mempertimbangkan untuk membuat dokumentasi yang diperlukan untuk keberhasilan perubahan dan peningkatan selanjutnya pada produk Anda.