Change request

Ceritanya...

Setelah kita selesai dengan dokumen-dokumen (business requirement, software design & spefication dan lain-lain) yang disetujui oleh client, kita mulai dengan membangun (develop) apa yang tertulis. Tapi kadang apa yang kita desain salah atau kurang tepat sehingga kita harus mengubah software yang telah kita buat. Perubahan juga bisa terjadi karena kesalahan pengertian terhadap bisnis proses atau memang karena proses bisnis yang berubah.

Perubahan bisnis proses akan membuat kita pusing kepala karena harus merubah aplikasi (software) yang kita buat, karena itu diperlukan "change request document" yang berguna untuk mengontrol perubahan selama project yang dapat mengakibatkan perubahan biaya, waktu, resource dan kualitas. Tanpa perjanjian yang jelas pada scope of project dan manajemen dokumen yang baik, perubahan bisnis akan lebih membuat kita pusing kepala. Oleh karena itu dokumen dan pengesahan (approval) terhadap dokumen menjadi penting.

Isi dokumen change request harus menjelaskan secara lengkap tentang perubahan yang terjadi. Komponen-komponen yang penting untuk ditulis dalam dokumen tersebut adalah:

• Requestor, orang yang menginisialisasi perubahan
• Waktu permintaan perubahan
  
• List dokumen yang terkait, dokumen lain yang berubah (document affected) akibat dokumen change request atau dokumen tambahan yang memperjelas
• Detail / deskripsi perubahan
  
• Penyebab perubahan
• Detail analisis
• Hasil evaluasi, keuntungan dan kerugian yang ditimbulkan dari change request
  
• Pengaruh adanya perubahan (impact)
• Pengaruh jika perubahan tidak dilakukan
• Pengaruh terhadap system/modul lain
  
• Solusi yang digunakan
• Perubahan biaya
• Perubahan resource (jumlah orang yang terlibat dalam proyek)
  
• Perubahan waktu pengerjaan (plan)
  
• List reviewer dan approver
• Status dokument, misalnya: Open, Approved for analysis, Approved for implementation, Rejected, Deffered, Closed
• Waktu selesai implementasi
  

Baik juga jika kita menambahakan atribut pengkategorian dari perubahan yang diminta, misalnya pengkategorian impact yang menunjukan seberapa besar pengaruh yang diakibatkan karena perubaha tersebut , scope of change yang menunjukan jenis perubahan, apakah perubahan bisnis, perubahan desain atau perubahan yang lain.

Pengalaman pribadi saya yang membuat "bete" adalah kejadian ketika client meminta untuk adanya perubahan kemudian kita mulai merespon perimtaan tersebut dengan membuka diskusi. Diskusi mulai panas dan memajang dengan pengaruh yang besar disana sini. Saat diskusi kita selalu memikirkan solusi detail yang akan dilakukan, karena client cukup educated maka kadang diskusi sampai pada desain interface secara umum. Kemudian kita mulai membuat dokumen change request berlembar-lembar, untuk memperjelas dibuat juga gambar-gambar dari mock-up screen yang akan dibuat.Cukup melelahkan. Kemudian setelah dokumen selesai kita mulai men-submit ke orang yang berhak melalukan approval. Karena impact-nya cukup besar, cost-nya pun besar, nah dengan mudahnya sang approver me-reject dokumen atau meminta diskusi ulang untuk solusi yang sederhana (solusi yang diambil dengan toleransi proses bisnis disana-sini). Bagaimana dengan kerjaan, waktu yang telah terbuang sebelumnya?? Inilah yang membuat saya "bete". Karenanya step "approved for analysis" sebelum kita mulai panjang lebar mediskusikan perubahan. Tapi ini terjadi pada proyek saya dimana tim bertindak sebagai kosultan tapi juga implementor.