Seberapa sering kita berurusan dengan “uncertainty” atau ketidakpastian dalam hidup? Dari mulai membuat goals pribadi tetapi di tengah jalan tidak berjalan sesuai rencana dan harus mengubah planning? Dalam artikel ini, kami akan membahas lebih detail mengenai prinsip the cone of uncertainty dalam manajemen proyek.
Steve McConnel, serang expert di bidang software engineering dan project management, menjelaskan bahwa semua experienced software professional tahu di setiap fase awal proyek kita tidak akan pernah tahu secara tepat berapa lama proyek tersebut akan dapat diselesaikan.
Ada dua alasan yang cukup mendasar:
- Tidak akan pernah ada proyek pengembagan software yang memiliki:
- Requirement yang persis sama.
- Pengguna yang persis sama.
- Business context yang persis sama.
- Teknologi yang sama.
- Prioritas dan batasan – batasan yang persis sama.
- Tahap analisis requirement pengembangan software tidak bisa 100% tepat mengcover semua requirement pengguna di awal proyek.
Dengan dua alasan tersebut, kita dapat menyimpulkan bahwa konsep The Cone of Uncertainty ini menggambarkan skala ketidakpastian yang besar di awal dan semakin menurun mendekati nol secara eksponensial seiring dengan perjalanan proyek dan tahapan pengembangan yang diselesaikan. Uncertainty atau ketidakpastian akan berkurang jika semakin detail project knowledge yang diketahui, tentang business flow, detail fitur, desain aplikasi, hingga proses implementasinya.
But life must go on. Pengembang aplikasi tetap harus memutuskan membuat proposal jika ingin ada proyek yang bisa dikerjakan. Perusahaan tetap harus membuat anggaran terkait kebutuhan software yang mereka butuhkan. Apa yang harus dilakukan untuk bisa “dealing with the cone”?
Mengutip dari website agilenutshell.com, setidaknya ada tiga cara yang dapat dilakukan, yaitu:
1. Berikan buffer dalam estimasi proyek.
Lakukan proses requirement gathering sebaik mungkin, libatkan orang teknis yang berpengalaman untuk melakukan estimasi. Lalu berikan buffer yang wajar dalam estimasi yang sudah didapatkan. Jangan terlalu besar karena calon klien pasti akan menolak angka yang tidak rasional, dan jangan terlalu kecil untuk jaga-jaga jika ada hal-hal yang tidak kita perkirakan.
2. Ukur dengan perbandingan proyek lainnya.
Kita tidak akan pernah bisa mengetahui detail pekerjaan di awal, namun intuisi kita sebagai seorang manusia, kita bisa membandingkan antara dua hal, lebih besar atau lebih kecil, kira-kira lebih besar dua kali lipat atau tiga kali lipat.
Prinsip ini juga dapat bekerja dalam estimasi kasar sebuah proyek. Ambil contoh satu proyek yang bisa menjadi pembanding lalu perkirakan besaran budget dan timeline-nya.
3. Kerjakan dengan skema agile.
Skema agile mengedepankan prinsip terbuka di awal dan transparansi pengerjaan. Sejak awal klien dan pengembang sudah memahami terkait tantangan the cone ini dan sepakat untuk menyelesaikannya dengan pendekatan metodologi yang mengedepankan kejujuran dan transparansi pengerjaan proyek. Pengembang akan melakukan estimasi kisaran waktu dan angka budget. Setelah beberapa iterasi pengerjaan dan waktu berjalan, product knowledge mulai diketahui, secara terbuka pengembang akan memberikan transparansi progres dan perkiraan pekerjaan selanjutnya sehingga klien memahami seberapa besar budget dan waktu yang dibutuhkan untuk menyelesaikan.
The Cone of Uncertainty adalah tantangan yang nyata dalam pengembangan software, maka semestinya baik pihak pengembang maupun klien dapat mawas diri untuk memahami agar proyek yang dikerjakan dapat mencapai tujuan yang diharapkan.
Estimasi tetap harus dilakukan namun perlu diingat bahwa estimasi tetaplah estimasi yang tidak akan pernah menjawab masa depan. Sebagaimana kata Steve Mc Connel, “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them”.
