Perusahaan tempat saya bekerja bertujuan untuk memiliki margin kesalahan maksimum 10%. Mereka mengharapkan analis untuk tidak melewatkan perkiraan lebih atau kurang dari 10%.
Saya tidak tahu harus berpikir apa, karena saya tidak dapat membandingkannya.
Apa yang bisa menjadi tolok ukur yang baik untuk diukur jika kita memperkirakan terlalu salah, kurang lebih? Berapa banyak (dalam%) yang menurut Anda boleh dilewatkan?
project-management
estimation
Tulio F.
sumber
sumber
Jawaban:
Kecuali jika Anda memperkirakan sesuatu yang sangat mirip dengan apa yang Anda dan rekan kerja Anda lakukan sebelumnya, +/- 10% sangat optimis. Manajemen Anda tidak memiliki banyak pengalaman dengan perangkat lunak, atau mereka tidak mengetahui Besar Batas Estimasi Perangkat Lunak . Makalah itu memiliki beberapa bahan pendukung yang menyertainya , dan banyak punditry dapat ditemukan.
Mari kita periksa sistem yang jauh lebih sederhana daripada proyek perangkat lunak biasa: Rubik's Cube. Anda dapat menyelesaikan posisi apa pun dalam 20 gerakan , maks. Tetapi karena Anda memperkirakan, Anda hanya dapat melihat kubus yang diberikan selama beberapa menit sebelum memberikan solusi. Bisakah Anda memberikan perkiraan yang bagus? Tidak, terkadang memperkirakan suatu proses membutuhkan waktu lebih lama daripada melakukan proses tersebut.
Sistem sederhana lain: Pinocchio. Otomat kayu, potongan hidungnya tumbuh ketika dia berbohong. Apa yang terjadi ketika Pinocchio sedang istirahat, dan kemudian berkata "Hidungku tumbuh"? Beberapa sistem tidak dapat menerima prediksi, tetapi tidak dapat diprediksi.
Kedua masalah ini terintegrasi pada sebagian besar sistem perangkat lunak. Karena itu, Anda tidak akan pernah mendapatkan taksiran mendekati +/- 10%.
Saran saya adalah memberikan perkiraan yang sangat empuk, bekerja seperti budak untuk menyelesaikan proyek secepat mungkin, dan kemudian terlihat sibuk sampai Anda berada dalam 10% di bawah atau lebih. Pada saat itu, umumkan kesuksesan yang spektakuler.
sumber
Saya akan sangat ragu tentang "margin kesalahan target" apa pun karena itu benar-benar tergantung pada proyek. Jika Anda mencoba memperkirakan berapa lama waktu yang diperlukan untuk menginstal, mengkonfigurasi, dan menyesuaikan sistem CRM baru di mana tidak ada yang cukup yakin jenis penyesuaian apa yang akan diperlukan dan jenis perubahan proses bisnis apa yang akan diperlukan dan perusahaan tidak memiliki riwayat proyek besar yang serupa, margin kesalahan Anda seharusnya cukup besar (yaitu Anda mungkin menebak bahwa itu akan memakan waktu 18 bulan +/- 50% dan penawaran 9-27 bulan). Seiring berjalannya proyek, spesifikasinya semakin jelas, keputusan dibuat tentang proses bisnis, pengembang Anda menjadi lebih nyaman, dll. Margin kesalahan tersebut harus semakin ketat. Jika Anda mencoba memperkirakan berapa lama akan membangun situs e-commerce dasar ke-101 ketika Anda Anda telah mendapatkan sejarah yang baik dari 100 yang pertama, Anda diharapkan dapat memberikan perkiraan yang jauh lebih akurat. Namun, sebagian besar proyek akan jatuh di suatu tempat di tengah.
Sekarang, jika Anda mengutip angka tunggal dan bukan rentang, jawabannya mungkin mulai mengutip rentang sehingga orang yang melakukan estimasi dapat menentukan seberapa akurat perkiraan perkiraan mereka.
sumber
Garis dasar yang baik akan didasarkan pada data nyata yang telah Anda kumpulkan.
Langkah pertama untuk melakukan ini adalah mencatat semua perkiraan . Langkah kedua adalah merekam hasil aktual . Jujurlah, jangan tergoda untuk 'menyesuaikan diri' dengan yang sebenarnya. Kumpulkan informasi ini secukupnya dan Anda memiliki beberapa data untuk basis statistik seberapa baik perkiraan Anda. Catatan, ini bisa / akan sangat bervariasi berdasarkan siapa yang melakukan estimasi dan siapa yang bekerja. Hanya dengan melakukan ini Anda dapat diharapkan untuk memberikan 'margin of error' yang merupakan sampah murni lainnya.
Tidak berhenti di situ juga; menganalisis apa yang menyebabkan estimasi tidak aktif dapat membantu meningkatkan keakuratan estimasi Anda di masa mendatang. Catatan: Mereka masih tetap estimasi , dan karena itu, hanya perkiraan .
Estimasi juga tidak selesai setelah estimasi pertama; ini adalah sesuatu yang dapat disesuaikan ketika proyek berlangsung seiring bertambahnya pengetahuan, hal ini mengurangi kemungkinan kesalahan saat Anda melanjutkan. Semakin Anda terbuka dengan komunikasi, kejutan-kejutan sebelumnya dibahas - membuat orang tidak terlalu terkejut dan memberikan lebih banyak waktu untuk melakukan penyesuaian baik dalam proyek maupun harapan pelanggan.
Kedua, mungkin cara yang lebih baik untuk menangani margin kesalahan adalah ' kepercayaan internal ' daripada hanya% margin kesalahan. Daripada Anda memperkirakan tanggal pengiriman pada interval kepercayaan, bukan tanggal tunggal.
PERT adalah salah satu contoh kerangka kerja untuk menangani estimasi berdasarkan penalaran statistik. Sebagai contoh:
"Berdasarkan apa yang saya ketahui sekarang, kami memiliki tingkat kepercayaan 90% yang dapat kami berikan dalam 8 bulan. Keyakinan 95% dalam 10 bulan, kepercayaan 99% dalam 2 tahun, dll."
Catatan di sini: Semakin yakin mereka menginginkan Anda, semakin besar perkiraannya. Tergantung pada kerumitannya (alias, seberapa akuratnya Anda), bisa jadi perbedaan kecil antara 80% dan 90%, atau bisa jadi sangat besar!
Terakhir - Semoga Sukses;) Jika Anda pernah memecahkan 'margin kesalahan maksimum' dalam estimasi perangkat lunak di mana Anda dapat menentukan sesuatu seperti 'semua perkiraan kami akan +/- 10%', pastikan untuk memesan film box-office untuk sisa kami di industri perangkat lunak. Saya sedang memikirkan sesuatu seperti persilangan antara Office Space dan The Matrix: D
sumber
Ini sebenarnya sangat tergantung pada ukuran dan kompleksitas proyek.
Jika perkiraan proyek Anda mengatakan 1 minggu - 10% masuk akal. Artinya +/- 1/2 hari.
Jika 1 bulan, 10% goyah - dari pengalaman saya, tidak mungkin untuk memperkirakan apa yang akan Anda temukan dalam 1 bulan.
Lebih dari satu bulan - semua taruhan dibatalkan :).
Ini adalah per pengembang - jadi untuk 4 tim pengembang, 1 minggu == 1 bulan.
Untuk tim pengembang 4, sebagian besar yang baik untuk datang dengan daftar fitur yang dapat dilakukan dalam 1 bulan, dan berada dalam 10% untuk fitur tersebut. Kemudian, perkirakan ulang untuk bulan berikutnya.
Saya telah membuat beberapa asumsi naif di sini
Anda harus memperhitungkannya .. tetapi ini adalah gagasan umum.
sumber
Ada banyak variabel:
Berapa lama proyeknya?
Bagaimana proyek akan dikelola? Air terjun? Tangkas? SCRUM?
Saya akan berasumsi dari pertanyaan Waterfall. Jika itu masalahnya, Anda diperkirakan akan gagal dalam beberapa persentase mengingat permintaan margin.
Jika jawabannya adalah beberapa metodologi Agile, terutama sesuatu seperti SCRUM. Tidak masalah berapa persentase marginnya. Margin kesalahan 50% pada Sprint 2 minggu adalah 1 minggu, pada Sprint 1 minggu adalah 2,5 hari, keduanya merupakan skenario kasus terburuk. Ini karena tanggal pengiriman diperkirakan kembali setiap Sprint, dan itu akan menjadi lebih dan lebih akurat dari waktu ke waktu, daripada semakin berkurang.
Dengan Waterfall 50% margin of error juga tidak pernah terdengar, tetapi lebih dari 12 bulan proyek yang 6 bulan, dan itu tidak benar-benar ditemukan / diakui itu buruk sampai 10 bulan ke 12.
sumber
Kembali ketika saya biasa memimpin tim perangkat lunak, kira-kira di sekitar batas Kapur / Tersier, kami benar-benar hampir mencapai +/- 10% pada estimasi. Itu sekitar +/- 15% jika ingatanku sangat cerdik. Tapi ini karena kami memperkirakan untuk hal - hal yang sudah kami lakukan : firmware komunikasi real-time yang relatif sederhana yang mengambil byte dari A dan memindahkannya ke B menggunakan bahasa yang kami kenal, dalam lingkungan waktu nyata yang dirancang oleh kami , berbicara dengan perangkat keras yang dirancang di rumah oleh orang-orang beberapa kantor jauhnya. Banyak varian kecil pada tema di atas, selama bertahun-tahun .
Berharap untuk mencapai tingkat kesalahan semacam ini dalam estimasi proyek perangkat lunak normal, terus terang, menggelikan . Ketika Anda melihat hal itu tampaknya tercapai, itu karena orang-orang over-estimasi dan empuk (melakukan hal-hal tambahan dan proyek kesayangan untuk menghabiskan anggaran), atau di bawah perkiraan dan bekerja seperti anjing di malam hari dan akhir pekan untuk menebus waktu.
sumber
Anda mungkin pernah mendengar 300% hal itu, kan?
Saya benar-benar menggunakannya. Sepenuhnya didasarkan pada apa yang saya lihat selama bertahun-tahun. Ketika saya mendengar satu atau dua hari, itu seminggu atau lebih yang harus dilakukan . Dan Diuji. Di Semua lingkungan. Dokumentasi diperbarui. Kegunaan diuji. Kinerja diuji. Load diuji. Beberapa jam benar-benar lebih seperti sehari.
Saya pikir kami benar-benar buruk dalam memperkirakan karena:
Jadi pada level tertinggi, dengan pelaku bisnis yang membutuhkan estimasi lebih dari 300%, apa yang akhirnya kami lakukan bertujuan untuk estimasi yang cukup baik tetapi dengan harga yang lebih tinggi dan lebih umum. "Kami akan memiliki fungsi edit pengguna" meskipun versi 1 hanya berarti untuk 1 grup pengguna untuk mengubah 1 bidang.
Ketika sampai pada "Apa margin kesalahan yang dapat diterima ketika memperkirakan durasi proyek?" Saya menemukan bahwa pendekatan ini, yang digunakan dalam banyak lingkungan Agile membantu mengubah pertanyaan menjadi apa fungsi minimum untuk mendapatkan versi alpha atau beta dan kemudian beralih di atasnya.
sumber