Bagaimana saya bisa memperkirakan proyek ketika saya perlu memasukkan kurva pembelajaran untuk teknologi baru?

11

Terkadang, ada proyek penelitian dan pengembangan di mana tidak ada yang diketahui sebelumnya tentang teknologi, konsep, dan klien. Namun, manajer masih membutuhkan perkiraan waktu. Apa yang bisa saya lakukan untuk menghasilkan estimasi yang berguna?

estimation

— pradnya
sumber

5

Ambil apa pun perkiraan Anda dalam teknologi yang dikenal dan pindahkan desimal satu tempat: P

— Rig

5

Baca buku estimasi perangkat lunak Steve McConnoll dan pahami apa yang membuat estimasi yang baik. Estimasi memiliki ketidakpastian untuk itu - jika tidak, itu tidak akan menjadi estimasi. Mengatakan "Ini mungkin memakan waktu antara tiga bulan hingga enam bulan, setelah menghabiskan satu bulan di atasnya, saya akan dapat mempersempitnya" harus diterima.

1

@MichaelT - komentar yang bagus. Satu hal yang dijamin untuk membuat perkiraan yang tidak tepat menjadi lebih enak adalah menyempurnakannya dari waktu ke waktu sehingga manajemen mendapatkan estimasi sisa pekerjaan yang semakin akurat. Satu hal yang dijamin membuat mereka kesal adalah proyek yang secara permanen akan berakhir dua minggu lagi.

— Carson63000

Inilah gunanya prototipe.

@ Carson63000 Saya memiliki versi sederhana dari kerucut ketidakpastian dalam ungkapan itu. Hal utama yang harus diambil dari ilustrasi itu adalah bahwa perkiraan 2-12 bulan tidak berarti berakhir pada 7 bulan pada akhir, tetapi estimasi tersebut dapat konvergen dari 2-12 ke 4-12 ke 8-12 hingga 10-12 hingga 12. Juga perhatikan bahwa kerucut asli memiliki kisaran 16x ketika konsep awal dilakukan.

13

Jujur, seperti yang ditulis Nassim Nicholas Taleb dalam bukunya The Black Swan: 'kita tidak bisa memprediksi'. Terutama karena tidak diketahui-tidak diketahui. Biasanya yang terbaik adalah mengomunikasikan fakta ini, fakta yang tidak dapat Anda prediksi, alih-alih mengkomunikasikan estimasi.

Seperti yang ditulis Taleb: lebih baik benar secara luas, daripada salah. Jadi, pastikan untuk mengomunikasikan fakta bahwa Anda kesulitan memperkirakan, dan gunakan hal-hal seperti 'kurva pembelajaran dalam teknologi baru' sebagai salah satu argumen. Ini berarti bahwa kisaran perkiraan Anda akan besar: 'proyek ini akan menelan biaya antara 100rb dan 500rb.'

Dengan mengatakan hal seperti itu, orang yang meminta Anda memperkirakan sesuatu menyadari bahwa segala sesuatunya tidak begitu sederhana.

— Marten Sytema
sumber

3

+1: Ini adalah satu-satunya jawaban yang benar. Ajari manajer Anda untuk merangkul yang tidak dikenal - jauh lebih mudah daripada memperkirakannya. - Lihat juga karya Steve McConnoll di construx.com.

— mattnz

2

Ini adalah salah satu jawaban yang paling salah di sini. Anda selalu bisa memperkirakan apa saja. Ada alat dan teknik untuk mendukungnya. Satu-satunya perbedaan adalah ketidakpastian. Anda mungkin memiliki varians 4x atau 5x antara estimasi Anda dan nilai aktual (terutama di awal proyek), tetapi itu tidak berarti bahwa Anda tidak boleh mencoba memperkirakan untuk berfungsi sebagai titik awal untuk perkiraan di masa depan.

— Thomas Owens

2

@ThomasOwens Anda benar, Anda tidak harus pergi begitu saja untuk itu. Tetapi pernyataan berani saya dimaksudkan untuk ditafsirkan: jangan membodohi diri sendiri, atau menipu bos Anda, tetapi terbuka pada kenyataan bahwa estimasi akan sulit! Karena jujur, tidak setiap manajer yang meminta perkiraan menyadari betapa sulit / tidak mungkin untuk membuatnya.

— Marten Sytema

Dalam pengalaman kerja pribadi saya, ketika melakukan pekerjaan lepas berdasarkan harga tetap, tingkat rata-rata per jam saya jauh lebih tinggi pada proyek kecil (seperti tambahan kecil untuk proyek yang ada), daripada pada proyek yang lebih besar (seringkali dari awal). Bahkan tidak linier. Kalau dipikir-pikir, saya seharusnya tidak mengambil yang lebih besar dengan harga tetap, atau setidaknya mendiskusikan di muka bahwa perkiraan itu sangat sulit untuk dilakukan, dan mencoba meyakinkan klien untuk bekerja pada dasar yang berbeda untuk menyebarkan risiko sedikit. .

— Marten Sytema

3

Hal pertama yang mutlak Anda butuhkan adalah beberapa gagasan tentang ruang lingkup. Semakin konkret semakin baik, tetapi segala bentuk persyaratan dapat digunakan untuk menghasilkan estimasi awal. Persyaratan pelanggan, visi dan ruang lingkup, dan dokumen konsep dapat digunakan sejak dini. Ketika persyaratan dan lingkungan operasi mulai menjadi lebih jelas, maka estimasi akan meningkat. Pemahaman yang lebih besar tentang klien (terutama antarmuka antara klien dan organisasi yang sedang berkembang), tim yang melakukan pekerjaan, teknologi yang akan digunakan, arsitektur sistem, dan desain terperinci semua akan berkontribusi pada perkiraan yang lebih akurat. Ini terlihat di Cone of Ketidakpastian.

Jika Anda menggunakan alat pemodelan parametrik, seperti SLIM atau COCOMO (Hanya Menengah atau Lanjutan, karena Basic tidak memperhitungkan driver biaya), maka harus ada faktor penyesuaian untuk ketidaktahuan teknologi. Sebagai contoh, COCOMO memiliki sejumlah besar penggerak biaya , termasuk beberapa yang secara khusus diarahkan untuk mengenal platform target serta bahasa dan alat yang digunakan untuk mengembangkan sistem. SLIM juga menjelaskan pengalaman keseluruhan tim pengembangan, yang harus mencakup pertimbangan alat dan teknologi yang digunakan.

Dengan teknik ini, output dari alat pemodelan biasanya divalidasi karena mereka telah berhasil digunakan untuk memperkirakan proyek perangkat lunak sebelumnya selama bertahun-tahun di banyak organisasi. Namun, output hanya sebaik input ke alat.

Jika Anda tidak menggunakan model parametrik untuk estimasi, Anda harus mempertimbangkan faktor-faktor ini saat membuat estimasi Anda. Ini menjadi lebih dari panggilan penilaian, tetapi Anda dapat mempertimbangkan kegiatan seperti membaca dokumentasi, mengatur lingkungan pengembangan baru, dan mengembangkan aplikasi sampel pada platform target atau dengan bahasa target.

Dalam hal ini, Anda perlu menjabarkan perkiraan Anda berdasarkan tugas dan dapat menggunakan penilaian profesional Anda untuk mendukungnya. Semoga, Anda memiliki data historis dan bukti konkret lainnya untuk dijadikan dasar perkiraan Anda. Kalau tidak, ini lebih merupakan perjuangan berat.

— Thomas Owens
sumber

3

Pisahkan waktu pelatihan dan penelitian utama dari waktu pengembangan. Bagi proyek menjadi beberapa sub proyek yang memiliki akhir yang bahagia. Pastikan Anda membuat bukti konsep setelah pelatihan.

Jika Anda baru mengenal teknologi, Anda tidak akan pernah mendekati waktu pengembangan yang sebenarnya. Angkat ini sebagai risiko di awal proyek dan berbaik hati dalam perkiraan Anda. Ini berlaku untuk teknologi inti yang Anda dan tim Anda tidak kenal.

— Tidak mungkin
sumber

1

Tergantung, saya menggunakan FPA ( Function Point Analysis ) sebagian besar waktu, tapi kami ke "pengembangan web enterprizey" ini, maksud saya, Anda tahu, perusahaan web Forbes 500.

Di sana tugas dapat selalu dibagi menjadi dua bagian: satu, yang sangat cocok dengan FPA: Anda memiliki antarmuka input, antarmuka output, file logis internal (alias. Tabel / tipe database yang akan diekspor), dan Anda memiliki sistem yang rumit dan tidak dikenal ini .

Dalam versi yang mudah, tugas kompleks adalah komponen yang sudah ditulis, hanya saja sulit dan tidak diketahui untuk berinteraksi dengannya.

Versi sulitnya adalah ketika harus ditulis, kemudian estimasi berbasis pilot, COCOMO, apa pun.

Namun, dua hal penting:

Setiap jenis sistem estimasi harus memiliki waktu kalibrasi untuk organisasi Anda. Anda tidak pernah berkembang sendirian, setidaknya ada pelanggan yang menunggu kode Anda (atau Anda tidak akan putus asa tentang hal ini, menulis kode untuk Anda sendiri). Pertanyaannya bukan "seberapa cepat dapat dikembangkan?", Tetapi "seberapa cepat dapat dikembangkan dengan Anda semua?"
Pernah saya memiliki seorang manajer yang membaca novel Black Swan dan maniak tentang hal itu. Dia mengatakan kepada kami bahwa tidak mungkin untuk memperkirakan, dan saya melakukan tepat seperti biasa untuk + -10% estimasi tanpa henti ...

— Aadaam
sumber

-2

Saya mengerjakan proyek yang sesuai dengan deskripsi itu secara teratur dan saya belum mengetahuinya! Syukurlah tempat saya bekerja, saya diberi keleluasaan untuk melakukan apa yang saya butuhkan dan tidak memiliki batas waktu yang sia-sia. Proyek tidak selalu berhasil dan itu hanya sebagian dari pekerjaan yang dilakukan dengan begitu banyak yang tidak diketahui. Perusahaan mendapatkan pengetahuan setiap kali.

Maaf itu tidak membantu sama sekali.

— mikato
sumber

-4

Perkirakan berapa lama untuk melakukan proyek serupa menggunakan teknologi yang sudah dikenal. Kalikan dengan 4. Tambahkan waktu belajar.

Jika perkiraannya terlalu pendek Anda akan terlihat naif dan sombong. jika perkiraannya terlalu besar Anda akan terlihat bodoh dan tidak kompeten. Pilihlah dengan bijak.

— CWallach
sumber

4

Mengapa 4? Kenapa tidak 5? 10? 33,3? ... Apakah ada ilmu di balik jawaban Anda atau Anda hanya memilih nomor acak? Termasuk bahwa dalam jawaban Anda mungkin membuatnya lebih bermanfaat.

— Bryan Oakley

pada catatan terkait, jangan malu jumlah besar. Kolega saya pernah memperkirakan beberapa modul ulang dalam 935 (sembilan tiga tiga lima) hari. Boss bilang kami tidak punya sebanyak itu dan memesan 60 hari. Rekannya melakukan apa yang mungkin terjadi pada usia 60 tahun. Hasilnya cukup menyusahkan tetapi dia tidak pernah disalahkan untuk itu. Harus mengakui bahwa versi 60 hari, betapapun merepotkan, memungkinkan kami untuk mendapatkan pelanggan yang cukup penting - yaitu dorongan bos membuat akal bisnis yang cukup baik. BTW pada akhirnya kami berhasil mendapatkan modul itu dalam bentuk, tetapi itu terjadi beberapa tahun kemudian dan upaya yang dilakukan lebih banyak di stadion baseball dengan perkiraan 935

— nyamuk