Apa margin kesalahan yang dapat diterima ketika memperkirakan durasi proyek?

23

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

3

Saya ingin margin kesalahan ditentukan oleh tim yang menyusun estimasi dan diajukan dengan estimasi tersebut. Pada umumnya, kesempatan pertama Anda pada perkiraan, hanya dengan deskripsi produk singkat dan tidak ada persyaratan yang solid akan memiliki margin kesalahan yang tinggi. Karena proyek semakin didefinisikan, perkiraan baru dapat dibuat dengan margin kesalahan yang lebih sedikit.

— Jesse C. Slicer

3

Apakah Anda mengatakan bahwa jika Anda datang dalam anggaran DI BAWAH oleh terlalu banyak, seseorang akan mendapat masalah?

— pdr

@ pdr Mereka tidak mengatakan apa-apa tentang konsekuensinya.

— Tulio F.

Harus pada pukul dua sore? Hanya bertanya.

— Peter K.

2

Saya sarankan melihat buku "Perkiraan Perangkat Lunak" oleh Steve McConnell. Ada berita gembira di sana bahwa keakuratan +/- 10% dimungkinkan - tetapi hanya mungkin pada proyek yang terkontrol dengan baik. Ini merujuk pada sebuah buku karya Jones pada tahun 1998.

25

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.

— Bruce Ediger
sumber

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. Seiring dengan Dilbert Anda seperti avatar melakukannya dengan benar untuk saya, terima kasih.

— Tulio F.

6

@tofs - Meminta perkiraan yang akurat (kecuali Anda hampir selalu melakukan hal yang sama berulang kali) harus menjadi bendera peringatan untuk Anda. Harapan mereka optimis secara tidak realistis, dan Anda akan menjadi orang yang tidak memenuhi mereka. Lebih baik memberi tahu mereka sekarang daripada setelah mereka menghabiskan banyak uang berdasarkan terlalu percaya diri dalam perkiraan. Juga, sepertinya kurang membuat alasan jika Anda memberi tahu mereka tentang hal ini sebelumnya.

— psr

@ PSR Saya kira saya harus memecahkan gelembung mereka, masalahnya adalah, itu datang dari atas. Jika saya tidak bisa, sayangnya saya harus menggunakan estimasi yang sangat padat .

— Tulio F.

3

Analogi Rubix Cube hanya bekerja jika Anda menempatkan setengah penyelesaian kubus, manajemen atas memutuskan bahwa warna solid pada semua wajah terlalu Web 1.0 dan mereka ingin garis-garis NoSql Ajax sebagai gantinya. Dan kemudian para pengguna memberi tahu Anda bahwa mereka tidak dapat menggunakannya kecuali memiliki sisi ketujuh, dengan gambar seekor kucing di atasnya ...

— Tacroy

1

Saya pernah outsourcing oleh perusahaan saya ke perusahaan lain yang mengatakan saya menerima +/- 10% margin kesalahan untuk perkiraan, yang sangat akurat. Mereka menuntut setiap tugas untuk diperkirakan sebelumnya dan merengek jika saya berani mengatakan bahwa saya tidak berhasil dalam perkiraan. Saya menggunakan waktu pribadi saya untuk memenuhi harapan mereka, pada akhirnya mereka mengakhiri kerja sama dengan kami mengatakan bahwa beberapa perbaikan bug saya gagal (mungkin 3 dari 50), orang-orang seperti itu memiliki mental kejam dan tidak akan pernah memperlakukan salah satu dari mereka sendiri seperti itu, untuk mereka saya hanya seorang pria outsourcing. Pelajaran bagus bagi saya, tidak pernah menggunakan waktu pribadi Anda.

— Ivan G

3

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.

— Gua Justin
sumber

Sementara Bruce Ediger membuat poin bagus tentang bagaimana seorang analis bisa mendekati masalah. Saya pikir Anda mengatakan sesuatu yang bisa saya gunakan ketika berdebat dengan bos saya.

— Tulio F.

1

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

— Dan McGrath
sumber

1

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

Semua pengembang dapat melakukan pekerjaan secara paralel.
Belum dianggap penguji - mereka harus punya waktu untuk menguji
Semua pengembang sama - Frontend, Backend, Desainer dll ...

Anda harus memperhitungkannya .. tetapi ini adalah gagasan umum.

— Chip
sumber

1

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.

0

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.

— Bob Moore
sumber

0

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:

Membantu orang lain
Terganggu
Melatih orang baru
Hal-hal lain muncul
Sakit atau tidak sehat
Meliputi orang yang pergi
Membutuhkan liburan atau cuti
Menjadi terganggu oleh orang lain
Ditahan oleh kelompok lain
Menjadi terlalu optimis dan realistis
Tidak mengalokasikan waktu untuk mengerjakan kegagalan tes intermiten
Mudah mengecualikan waktu untuk pengujian, terutama menulis tes otomatis

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.

— Michael Durrant
sumber