Estimasi proyek dengan meningkatnya kebutuhan


8

Membuat estimasi proyek dengan memberikan seperangkat persyaratan adalah satu hal.

Tapi, apa yang terjadi ketika pengguna tiba-tiba mulai mengubahnya dengan cepat dan mulai menambahkan persyaratan baru ke set yang sudah ditentukan? Dan bahkan menjadi marah tentang mengapa proyek ini tidak selesai dalam kerangka waktu yang direncanakan semula.

Bagaimana saya harus menghadapi situasi ini? Mengusulkan beberapa metodologi dan bacaan bisa membantu.


2
Ini mungkin lebih baik ditanyakan di pm.stackexchange.com
Bill the Lizard

6
Ini umumnya dikenal sebagai creep lingkup.
P.Brian.Mackey

2
Metodologi tidak berguna di sini. Penting untuk memperjelas bahwa perubahan persyaratan dikenakan biaya, dan itu adalah masalah hubungan pelanggan. Beberapa metodologi lebih baik daripada yang lain dalam menangani perubahan, tetapi tidak ada yang akan menangani creep lingkup tanpa biaya tambahan waktu.
David Thornley

waktu * = persyaratan ++;
Aditya P

Jawaban:


11

Anda harus menjelaskan kepada pelanggan bahwa perubahan persyaratan juga merupakan perubahan dalam cakupan, dan memberikan pembaruan pada perkiraan setiap kali ada perubahan pada persyaratan.

Estimasi proyek disebut estimasi karena suatu alasan. Itu bukan janji. Jika pelanggan ingin membuat janji, itu kesepakatan yang berbeda; Anda sekarang harus memberikan perkiraan yang jauh lebih besar yang memiliki probabilitas keberhasilan yang lebih tinggi, menggunakan persyaratan beku .

Sebagian besar perkiraan proyek menyediakan tingkat padding tertentu, di mana saja dari 20% hingga 100% waktu premium (atau lebih) di atas perkiraan ideal. Pastikan estimasi Anda menyertakan lapisan ini.

Ada metodologi tangkas yang memberikan visibilitas yang lebih baik bagi pelanggan, sehingga mereka dapat memiliki gagasan yang lebih baik tentang upaya yang terlibat, dan bagaimana perubahannya memengaruhi jadwal.


Saya gagal melihat bagaimana tangkas membantu. Bahkan kemungkinan besar menghalangi visibilitas karena tanggal proyek akhir lebih kabur. Sedangkan pendekatan air terjun yang lebih akan mengatakan, tentu saja jika kita menambahkan persyaratan ini akan menambah 3 bulan untuk jadwal dan X dolar untuk biaya.
Dunk

1
@Dunk: Yang saya maksud dengan visibilitas adalah kemampuan pelanggan untuk "melihat" bagaimana perubahannya memengaruhi proyek. Visibilitas bukanlah janji; itu hanya kebijakan pintu terbuka. Air terjun tidak menjamin perkiraan yang baik. Jika ada, air terjun harus bersikeras bahwa pelanggan tidak melakukan perubahan apa pun , jika perkiraan itu berguna.
Robert Harvey

1
Agile memberi pelanggan ilusi berada dalam lingkaran, yang pada gilirannya memberi mereka beberapa gagasan tentang dampak perubahan persyaratan mereka terhadap siklus pengembangan. Dengan demikian dapat menjadi alat untuk mengajarkan pelanggan tentang apa yang dapat mereka lakukan terhadap suatu proyek.
jwenting

6

Anda perlu memperbarui perkiraan ketika mereka memperbarui persyaratan, dan memiliki spesifikasi yang ditentukan tentang apa yang akan diterima klien sebagai "selesai". "Perkiraan saya sebelumnya adalah untuk set fitur X, Y. Jika Anda ingin saya menambahkan Z, saya memperkirakan bahwa akan memperpanjang tanggal pengiriman dengan ...", dll


4

Anda harus secara formal mengomunikasikan dampak pada jadwal dan biaya kepada pelanggan dan manajemen ketika mengubah persyaratan atau menambahkan yang baru. Lakukan yang terbaik untuk memaksakan mekanisme persetujuan resmi sehingga mereka berpikir secara mendalam sebelum mereka meminta sesuatu yang baru atau perubahan apa pun. Kalau tidak, Anda akan terus mendengar "Saya ingin Anda menambahkan XYZ" dan kemudian "Apakah saya mengatakan XYZ maksud saya ABC".


Adakah sumber daya yang disarankan / bacaan, berbagi pengalaman tentang pendekatan formal ini?
TheBoyan

1
Yang saya maksud adalah melakukan yang berikut: (1) Minta satu orang (mungkin per topik) untuk bertindak sebagai penyedia persyaratan. (2) Hanya terima permintaan tertulis. Jika Anda mendapatkan permintaan melalui telepon atau komunikasi verbal atau rapat, Anda harus menuliskan berita acara dan persyaratannya dan mengatakan dengan jelas apa yang akan Anda lakukan dan mengirimkannya melalui email atau format tertulis dan memasukkan waktu tambahan yang diperlukan. (3) ketika memberi tahu pemimpin teknis Anda tentang area yang terkena dampak dari aplikasi sehingga ia dapat memberi saran kepada Anda tentang pendekatan yang lebih baik atau mendukung Anda dalam keputusan Anda.
M.Sameer

1
(4) Jika Anda menerima permintaan dalam format tertulis tetapi tidak terorganisir atau tidak jelas, Anda dapat mengusulkan template untuk Permintaan Perubahan. (5) Melacak semua permintaan perubahan karena sangat penting bagi manajer proyek untuk mengetahui ketidakstabilan persyaratan. Jika mau, Anda dapat membaca tentang Definisi dan Manajemen Persyaratan, Manajemen Perubahan, dan CMMI.
M.Sameer

3

Pikirkan proyek Anda sebagai segitiga (seorang teman PM saya benar-benar membuat segitiga fisik yang ia gunakan untuk efek tambahan). Tepi disebut waktu , biaya , dan ruang lingkup . Anda memberi tahu klien Anda bahwa ia dapat memiliki kendali atas 2 sisi, tetapi Anda (yang bertanggung jawab atas pengiriman) harus memiliki kendali atas setidaknya satu sisi.

Jadi, Anda dapat melakukannya dengan cepat dan murah - tetapi kemudian Anda harus memiliki kekuatan untuk memotong ruang lingkup.

Atau, Anda bisa mendapatkan lebih banyak fitur, tetapi itu akan memakan waktu lebih banyak atau lebih banyak uang.

Baca lebih lanjut di http://en.wikipedia.org/wiki/Project_triangle


2

Anda dapat mencoba menerapkan Scrum , metodologi tangkas yang, menurut situasi Anda, bisa sangat membantu.

Dari Wikipedia:

Scrum adalah kerangka proses yang berisi serangkaian praktik dan peran yang telah ditentukan. Peran utama dalam Scrum adalah:

  1. "ScrumMaster", yang mengelola proses (biasanya sebagai pengganti manajer proyek)
  2. "Pemilik Produk", yang mewakili pemangku kepentingan dan bisnis
  3. "Tim", kelompok lintas-fungsional sekitar 7 orang yang melakukan analisis, desain, implementasi, pengujian aktual, dll.

Selama setiap "sprint", biasanya periode dua hingga empat minggu (dengan panjangnya diputuskan oleh tim), tim menciptakan peningkatan produk yang berpotensi dapat dikirim (misalnya, perangkat lunak yang berfungsi dan diuji). Seperangkat fitur yang masuk dalam sprint berasal dari produk “jaminan simpanan”, yang merupakan serangkaian persyaratan pekerjaan tingkat tinggi yang harus dilakukan. Item backlog mana yang masuk ke sprint ditentukan selama pertemuan perencanaan sprint.


1
Proyek yang lebih besar kemungkinan akan membutuhkan lebih banyak waktu, scrum atau tanpa scrum. Agile kemungkinan akan mempermudah pertukaran fitur, dan membuatnya lebih mudah untuk mengirimkan sesuatu yang bermanfaat jika tenggat waktu tiba-tiba diberlakukan. Itu tidak akan menghentikan fitur creep.
David Thornley

2

Ini bukan tentang metodologi, tetapi tentang komunikasi dengan pelanggan.

Saya memiliki banyak situasi di mana pelanggan ingin terus-menerus menambahkan fitur baru ke proyek yang belum selesai, dan terkejut mengapa hal itu akan meningkatkan keseluruhan biaya dan penundaan. Konteks dan kepribadian para pelanggan itu berbeda, itu membutuhkan pendekatan yang berbeda, tetapi saya dapat mencoba untuk mengisolasi beberapa pedoman dan saran:

  • Pastikan bahwa pelanggan memiliki akses ke informasi umum yang diperlukan untuk memahami mengapa perubahan persyaratan dapat berdampak pada biaya dan keterlambatan . Dengan kata lain, terbitkan beberapa artikel tentang hal-hal itu, menjelaskan apa yang orang non-teknis mungkin tidak tahu sama sekali.

Misalnya, bagi kebanyakan orang, benar-benar aneh bahwa perubahan yang mereka anggap kecil mungkin berdampak besar pada proyek dan menjadi sangat mahal (lihat contoh dalam pertanyaan saya ). Jika mereka meminta untuk melakukan beberapa perubahan, dan setiap kali Anda memberi tahu mereka, tanpa menjelaskan apa pun, bahwa mereka harus membayar ribuan dolar ketika mereka mengharapkannya secara gratis atau untuk beberapa puluh dolar, mereka mungkin akan berpikir Anda hanya mencuri uang mereka. Ini terutama benar karena beberapa programmer dan perusahaan perangkat lunak yang tidak etis mengembangkan produk yang tidak dapat dipertahankan (jadi Anda tidak dapat meminta untuk mengubahnya nanti oleh pengembang normal), kemudian meminta Anda membayar terlalu banyak untuk setiap modifikasi.

  • Pastikan bahwa pelanggan telah memahami mengapa perubahan spesifik yang diinginkannya berdampak pada biaya . Untuk itu, Anda dapat memberinya tautan ke artikel Anda (lihat poin sebelumnya), atau hanya meringkas, dengan cara non-teknis, apa yang diperlukan untuk membuat perubahan yang diminta.

Penjelasan seperti itu juga merupakan ide yang bagus karena memungkinkan pelanggan Anda untuk memiliki pemahaman yang lebih baik tentang produk dan perubahannya. Dalam beberapa kasus, beberapa pelanggan saya berakhir dengan mengatakan bahwa perubahan yang mereka inginkan tidak terlalu pintar, dan bahwa mereka akan melakukannya dengan cara lain. Anda juga dapat menyarankan beberapa hal. Ini sangat dihargai oleh beberapa pelanggan (peringatan: beberapa lainnya membencinya), dan menunjukkan bahwa Anda tahu apa yang Anda bicarakan (dengan membandingkannya dengan kode monyet yang hanya menerjemahkan persyaratan ke dalam kode, tanpa terlalu memikirkan pendekatan yang mungkin) .

  • Pastikan bahwa pelanggan tidak dapat melakukan apa pun yang dia inginkan, kecuali dia benar-benar yakin. Bagi sebagian orang, satu-satunya cara adalah mengunci persyaratan secara definitif sebelum mulai kode . Kalau tidak, itu adalah bencana, dan proyek tidak akan pernah berakhir . Bagi yang lain, itu adalah ide yang baik untuk tidak pernah melihat proyek yang tidak terintimidasi (secara umum pelanggan saya memiliki akses langsung ke produk yang tidak terintervasi sejak dini, sehingga mereka dapat membuat komentar / penyesuaian lebih awal juga).

Misalnya, saya memiliki pelanggan yang, setelah mengirim persyaratan "final", mengirim, rata-rata, sepuluh surat per hari dengan sepuluh perubahan persyaratan, pergi dari modifikasi kecil ("Bisakah Anda mengubah lebar perbatasan zona tengah di halaman beranda?) dari tiga hingga enam piksel? ") hingga perubahan yang memengaruhi seluruh proyek (setelah dua bulan pengembangan, satu minggu sebelum rilis:" Akhirnya, saya pikir ASP.NET adalah ide yang buruk. Bisakah Anda beralih ke PHP? " ).

Jadi untuk pelanggan itu , kami terpaksa mengunci semua persyaratan sebelum menulis kode. Itu tertulis dalam kontrak. Tidak ada perubahan yang diterima sebelum rilis final.

Itu tidak terlalu buruk, akhirnya, karena anehnya kami diizinkan untuk sangat terorganisir: proyek dirilis, sesuai dengan persyaratan lama, dan kemudian, beberapa hari kemudian, kami memulai versi berikutnya dari awal dengan set yang sama sekali berbeda persyaratan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.