Sebelum berkuliah di teknik informatika, definisi kata dokumentasi yang saya kenal adalah foto sebagai tebukti suatu aktivitas, misalnya Pramuka ada acara kemping maka dokumentasinya ya foto-foto selama kegiatannya.
Pemahaman ini mulai bergeser sejak mata kuliah Rekayasa Perangkat Lunak dan Manajemen Proyek Teknologi Informasi. Foto bukan lagi istilah yang satu-satunya diakui sebagai arti dari dokumentasi. Maka dokumenstasi ternyata sangat luas. Singkat cerita apa yang menjadi rencana, analisis, perimbangan, engambilan keputusan, proses eksekusi, penjaminan kualitas, termasuk did alamnya pengujian, itu merupakan bahan-bahan yang harus diwujudkan dalam sebuah bukti yang disusun secara sistematis dan resmi. Misalnya kita meng0install OS CentOS di laptop kita, maka perlu dibuat sebuah dokumentasi yang memuat versi centOS apa yang dipergunakan, profil komputer kita (RAM-nya brapa, HDD-nya berapa), kemudian ketika selesai diinstall maka harus terdapat bukti bahwa OS yang terpasang memang versi yang kita install. Tak lupa kita buat daftar risiko yang mungkin dihadapi di kemudian hari, dalam kasus ini adalah efek memilih CentOS.
Kenapa harus ada dokumentasi
- Kebutuhan konfigurasi sistem yang mempunyai integritas dan kredibilitas
- Memudahkan pengecekan di kemudian hari terhadap ancaman infrastruktur IT
- Memudahkan transfer ilmu, khususnya saat serah terima objek
- Mempercepat penelusuran sebab permasalahan yang terjadai di dalam sistem dengna melihat runutan proses debuging.
Namun dalam sebuah proyek website, tantangan yang kerap terjadi adalah kekurangakuratan dokumentasi yang dibuat. Kondisi yang dominan terjadi adalah developer membuat cara memakai aplikasi benar-benar dari sudut pandang front-end user alias mereka yang membuka website tersebut via browser. Bagaimana pengelola konten melakukan updating alias pemutakhiran? Langsung TOT alias Training of Trainer yang tanpa jejak tertulis mengenai step-step yang harus dilakukan esok hari pasca-TOT tentang penggunaannya. Itu baru versi pertama.
Ada pula yang membuat dokumentasi yang berisi bagaimana front-end user memakai aplikasi serta bagaimana pengelola konten melakukan proses pengangkatan konten ke dalam live version. Untuk kondisi kedua ini, mmm lebih baiklah, walau demikian masih ditemui kenyataan bahwa penyusun dokumentasi agak 'malas' melakukan segementasi pengguna website. Akibatnya dia membuat dokumentasi hanya satu-satunya, semua ada di situlah intinya.
Kedua kondisi di atas merupakan yang mendominasi kepenatan menyusun dokumentasi. Maka tidak heran, keberlanjutan maintenance website seringkali anjlok dari ekspektasi awal.
Buatlah tiga kelas user
Terdapat tiga kelas user yang menjadi klasfikasi umum terhadap siapa yang patut menerima dokumentasi. Ketiga kelas ini adalah
Front-end user, yaitu masyarakat yang mengakses website ini, terlepas dari apakah diterapkan konsep UGC atau tidak.
Content editor, yaitu tim yang bertugas melakukan pengelolaaan, pengarsipan, dan pemutakhiran konten
IT developer, yaitu tim yang bertugas melakukan maintenance serta melakukan penanganan terhadap keberlanjutan fitur di salam proyek
Pertama-tama masing-masing kelas user perlu dibuat masing-masing user manual yang memang sudah fokus, baik bahasa maupun esensi agar cocok sesuai kebuhan tiap user, dan tentunya menjaga integritas aplikasi.
Kedua, kenapa sih harus ada kelas IT devloper? Ini kembali lagi ke alasan kenapa harus ada konfigurasi di nomor 1 s.d. 4. Seringkali ketika telah dilaksanakan serah terima aplikasi, maka PIC-nya tidak tahu bagaimana cara melakukan perubahan yang sifatnya minor. Belum lagi bila ditemukan bugs maka terjdi kesulitan untuk mengetahui sebabnya.
Sebagai contoh website Kaskus.co.id yang penggunanya dapat diklasifikasi menjadi 4 macam:
- User biasa yang hanya membaca artikel. Untuk user jenis ini, jenis dokumentasi yang cocok adalah bagaimana caranya menelusuri informasi yang ada di Kaskus
- User yang memiliki akun sehingga bisa membuat artikel, comment dan aktivitas lain yang bersifat UGC (user generated content), sehingga dokumentasi khusus untuk mereka adalah yang berisi bagaimana caranya mengelola konten miliki mereka, misalnya kalau mau nge-post artikel klik yang mana, kalau mau nyisipin gambar begimana ukuran standarnya.
- User yang bertugas melakukan update terhadap konten, biasanya editor. Dibutuhkan dokumentasi yang lebih rumit lagi, misalnya bagaimana mengganti banner di halaman homepage, bagaimana memiih editor pick, hingga bagaimana mengganti isi konten statis yang hanya bisa diubah oleh editor. Dokumentasi yang jenis ini tentu peredarannya sangat terbatas dan rahasia.
- User yang berperan sebagai developer. Bagaimana kalau tiba-tiba jumlah visitor di Google Analytics berbeda dengan angka yang muncul di dashboard, bagaimana caranya menampilkan halaman under-maintenance, hingga bagaimana ketika dilakukan perombakan visual. Nah hal-hal yang seperti itu perlu dibuat dokumentasi khusus yang memang ditujukan kepada developer. Sehingga ketika di suatu hari nanti ada request menambahkan form isian baru di dashboard milik user, si developer ini tahu bagaimana caranya, bukan seenaknya memanggil si programmer yang membuatnya.
#YukDisiplinDalamDokumentasiProgram:)
No Response to "User Documentation Diversity"
Posting Komentar