Perkiraan yang tidak akurat adalah salah satu tantangan manajemen proyek yang paling populer. Saat memulai proyek TI baru, Anda ingin mengetahui dua hal: berapa lama waktu yang dibutuhkan dan berapa biayanya. Untuk menjawab pertanyaan-pertanyaan ini, Anda harus memperkirakan proyek yang akan Anda jalankan. Tidak ada aturan ajaib yang mengatakan bahwa Proyek X membutuhkan waktu 12 minggu dan biaya $150.000. Atau situs web seperti Y membutuhkan waktu 10 minggu untuk dikembangkan dan menghabiskan biaya $100.000.
Apa yang akan Anda pelajari dari artikel ini:
- Bagaimana manajer proyek mempersiapkan estimasi biaya dalam manajemen proyek?
- Teknik estimasi apa yang berguna untuk estimasi proyek?
- Bagaimana perencanaan yang diperlukan untuk mempersiapkan diri Anda dalam memperkirakan biaya dengan rumus?
Anda tidak dapat menilai jadwal atau biaya proyek tanpa estimasi yang menyeluruh, bahkan jika ruang lingkup proyek tersebut sangat mirip dengan apa yang telah Anda lakukan sebelumnya. Namun, masalahnya menjadi lebih buruk: Estimasi tidak akan pernah memberikan jawaban yang 100% akurat untuk pertanyaan-pertanyaan ini. Jadi, mengapa kita melakukan estimasi? Karena ini adalah satu-satunya cara untuk membuat asumsi tentang jadwal dan anggaran proyek, beban kerja, dan sumber daya yang dibutuhkan untuk menyelesaikannya.
Dengan memperkirakan proyek, Anda juga dapat menjadwalkan karyawan dengan pengalaman dan keahlian yang tepat. Yang bisa Anda lakukan adalah menggunakan metodologi dan teknik yang memungkinkan Anda memperkirakan dengan akurasi semaksimal mungkin. Berikut ini cara menggunakan metodologi Agile dan teknik Planning Poker untuk membuat estimasi yang berarti untuk proyek Anda.
James Grenning mengembangkan sesi perencanaan poker yang dikenal dengan strateginya pada tahun 2002 yang disebut Scrum poker. Pada awal tahun 1950-an, metode estimasi yang digunakannya, Wide band Delphi, terlalu memakan waktu dan memiliki keterbatasan lainnya. Dalam kasus Grenning, rencana poker awalnya adalah untuk mengatasi masalah di mana para pemain terlalu bersemangat dan terlalu fokus untuk menang. Mike Cohn, pendiri aliansi Agile dan aliansi Scrum, kemudian menggunakan teknik ini untuk sebuah artikel berjudul Agile Estimation and Planning.
Memulai sebuah proyek yang sukses sebagian besar bergantung pada seberapa baik Anda memahami apa yang sebenarnya ingin dicapai. Itu termasuk:
- Memahami ekspektasi klien Anda
- Memahami tujuan proyek dan sasaran utamanya
- Membuat daftar fitur yang diperlukan
Setelah Anda mendapatkan penjelasan singkat dari klien dan memiliki informasi sebanyak mungkin tentang persyaratan proyek, Anda bisa membuat daftar semua fitur dan menyampaikannya kepada tim Anda.
Untuk melakukannya, buatlah daftar produk yang terdiri dari semua fitur yang harus dilakukan. Anda kemudian dapat memprioritaskannya, mengevaluasi kompleksitasnya, dan memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikannya. Backlog produk yang tepat harus terdiri dari:
- Cerita pengguna - menjelaskan tindakan yang dapat dilakukan pengguna di setiap langkah penggunaan produk
- Kriteria penerimaan - daftar item yang dibutuhkan agar cerita dapat diselesaikan
- Poin cerita - memperkirakan jumlah pekerjaan, risiko, dan kompleksitas dalam nilai poin relatif
- Tugas untuk cerita pengguna - daftar tugas yang perlu dilakukan untuk menyampaikan cerita pengguna
Sangat penting untuk melibatkan tim pengembangan dalam membuat dan memprioritaskan backlog produk untuk memastikan penilaian yang akurat dan realistis.
Dengan daftar fitur yang sudah siap, tetapkan prioritas untuk masing-masing fitur. Anda dapat menggunakan metode analisis MoSCoW untuk mengurutkannya:
- Harus memiliki
- Seharusnya
- Bisa saja
- Tidak akan memiliki
Dalam mengembangkan sebuah proyek, fokuslah pada hal-hal yang harus Anda berikan sejak awal. Membangun MVP memberi Anda kemungkinan untuk menguji hipotesis tentang ide Anda sebelum menyelesaikan keseluruhan proyek, menunjukkannya kepada pemangku kepentingan atau pengguna beta, dan mengumpulkan umpan balik yang penting untuk pengembangan lebih lanjut dari fitur lainnya.
Menetapkan prioritas juga dapat membantu Anda dalam memperkirakan proyek. Ketika Anda fokus pada fitur utama dan fitur yang harus dikerjakan terlebih dahulu, Anda dapat membuat asumsi yang lebih akurat tentang perkiraan penyelesaiannya. Untuk fitur yang "bisa saja", Anda dapat memulai dengan perkiraan kasar, karena fitur-fitur tersebut masih dalam proses pengembangan dan banyak yang dapat berubah pada saat tim Anda menyelesaikannya (dan jika tim Anda menyelesaikannya, setelah mengumpulkan umpan balik tentang MVP Anda, Anda dapat melakukan pivot dan tidak menyertakan semua fungsi yang direncanakan pada awalnya).
Namun, penting untuk memperkirakan semua fitur, terlepas dari prioritasnya (kecuali yang "tidak akan ada", tentu saja), karena Anda ingin mendapatkan gambaran umum dari keseluruhan proyek sekaligus. Dan ketika Anda memasuki tahap selanjutnya dari proyek, Anda dapat mengevaluasi kembali ruang lingkup pekerjaan, untuk memastikan perkiraan Anda tetap akurat.
Sekarang setelah Anda menyelesaikan backlog produk Anda, sekarang saatnya untuk memperkirakan setiap itemnya. Untuk melakukannya, kita menggunakan story point. Poin-poin ini adalah unit yang digunakan tim Agile untuk mengevaluasi pekerjaan yang diperlukan untuk menyelesaikan setiap item dari backlog. Poin cerita membantu untuk memberikan nilai relatif pada item-item backlog produk. Mereka tidak terkait dengan waktu dan dapat memiliki nilai yang berbeda untuk tim yang berbeda, sehingga tidak membawa nilai emosional. Dengan demikian, kemungkinan besar anggota tim tidak akan menambah estimasi hanya untuk berjaga-jaga. Planning Poker membantu tim perangkat lunak untuk merencanakan alur kerja dan meningkatkan tingkat pengiriman proyek.
Dengan menggunakan poin cerita, tim dapat memperkirakan:
Sesi Perencanaan adalah salah satu teknik estimasi tingkat bruto, menggunakan versi modifikasi dari deret Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100. Untuk memperkirakan item dari simpanan produk, anggota tim mendapatkan set kartu poker perencanaan yang sama dengan angka-angka di atasnya. Kemudian, setelah pengenalan singkat tentang item backlog produk oleh Pemilik Produk (yang tidak memilih) dan diskusi, mereka secara pribadi memilih kartu dengan jumlah poin cerita yang mereka anggap relevan dengan jumlah pekerjaan yang diperlukan untuk menyelesaikan item ini dan mengungkapkannya pada saat yang bersamaan.
Jika angkanya berbeda, anggota tim mendiskusikan mengapa mereka memilih jumlah poin cerita tersebut, dan kemudian melakukan pemungutan suara lagi. Ini adalah bagian dari proses poker perencanaan, sebuah metode estimasi berbasis konsensus yang digunakan dalam Agile untuk memperkirakan upaya untuk cerita pengguna. Mereka melakukannya hingga mencapai konsensus dan kemudian beralih ke item berikutnya dari product backlog. Dan jika jumlah yang disepakati tinggi, katakanlah 20, 40, atau lebih tinggi, itu berarti sebuah cerita mungkin membutuhkan terlalu banyak pekerjaan untuk satu sprint dan mungkin perlu dipecah menjadi tugas-tugas yang lebih kecil. Idealnya, presentasi item, diskusi, dan pemungutan suara memakan waktu sekitar dua menit, yang memungkinkan untuk memperkirakan seluruh backlog dalam waktu singkat. Tetapi karena intinya di sini adalah untuk memperkirakan seluruh backlog sekaligus, luangkan waktu Anda, dan jangan khawatir ketika beberapa cerita membutuhkan waktu sedikit lebih lama untuk dinilai.
Kecepatan tim menunjukkan kepada Anda berapa kecepatan pengembangan proyek. Ini membantu dalam memahami dua hal:
- Jumlah pekerjaan yang dapat dilakukan tim Anda dalam satu sprint
- Berapa perkiraan tanggal penyelesaian seluruh ruang lingkup, dengan asumsi bahwa itu sudah pasti
Kecepatannya berbeda untuk setiap tim. Anda dapat menilainya setelah iterasi awal ketika tim Anda telah mengerjakan beberapa fitur. Misalnya, jika Anda telah memasukkan empat item backlog produk pada iterasi pertama dengan jumlah total 20 poin cerita, dan tim menyelesaikan tiga di antaranya yang setara dengan 15 poin cerita, ini adalah kecepatan tim Anda saat ini. Ingatlah bahwa hanya item yang sudah selesai yang dihitung. Meskipun mereka berhasil memulai item keempat tetapi belum menyelesaikannya, itu tidak dihitung.
Scrum master memainkan peran penting dalam memfasilitasi proses estimasi dan memastikan penilaian yang akurat selama sesi ini.
Setelah menegosiasikan poin-poin cerita dan menilai kecepatan tim, Anda dapat menentukan jadwal proyek. Untuk melakukannya, jumlahkan kecepatan tim dari tiga iterasi terakhir dan bagi dengan tiga. Misalnya, jika kecepatan dari iterasi tersebut adalah 20, 23, dan 17, kecepatan rata-rata akan sama dengan sekitar 20 poin. Jika jumlah total pekerjaan diperkirakan mencapai 100 titik cerita, maka, dengan kecepatan rata-rata 20 titik, dibutuhkan 5 iterasi untuk menyelesaikan proyek tersebut. Dengan asumsi bahwa satu iterasi membutuhkan waktu dua minggu, Anda harus menyelesaikan proyek tersebut dalam waktu 10 minggu.
Untuk menentukan anggaran proyek Anda, Anda dapat menggunakan rumus dasar ini: (total Story Points / Velocity * jam kerja tim per sprint) + biaya non-tenaga kerja = estimasi anggaran. Setelah jumlah total poin cerita dibagi dengan kecepatan rata-rata, kalikan jumlah sprint dengan 40 jam per minggu per anggota tim untuk mendapatkan biaya tenaga kerja. Kemudian tambahkan biaya non-tenaga kerja seperti biaya modal, biaya peralatan, biaya pemeliharaan, biaya pelatihan, dll. Sebagai contoh, kami memiliki proyek yang diperkirakan memiliki 100 poin cerita dan kecepatan rata-rata tim kami adalah 20. Menugaskan 5 orang tim ke proyek dengan tarif $50 per jam, maka jam kerja tim per sprint bernilai $20.000 dan $100.000 untuk 5 sprint. Dengan biaya non-tenaga kerja hipotetis sebesar $50.000, estimasi anggaran untuk proyek kita adalah $150.000. Dengan mempertimbangkan interval kepercayaan pada tingkat keteladanan 80-120%, kisaran anggaran yang dilaporkan sekarang adalah $120.000 hingga $180.000.
Ingatlah bahwa tidak ada estimasi yang 100% akurat. Sebaiknya estimasi ulang proyek Anda setiap beberapa kali iterasi, karena banyak hal, seperti ketersediaan sumber daya, kecepatan tim, atau cakupan proyek, dapat berubah seiring waktu. Dengan melakukan estimasi ulang, Anda memastikan bahwa estimasi Anda adalah yang terbaru. Menggunakan perangkat lunak pelacakan waktu dan penjadwalan sumber daya juga akan membantu Anda mengelola ketersediaan tim dan menugaskan mereka kembali jika diperlukan. Dengan teknik dan alat bantu yang tepat, Anda bisa membuat estimasi Anda lebih andal dan merencanakan proyek berikutnya dengan lebih baik.
Estimasi proyek yang akurat sangat penting untuk manajemen proyek yang sukses. Dengan memahami ekspektasi dan tujuan, membuat daftar produk yang terperinci, memprioritaskan fitur, dan menggunakan teknik seperti poin cerita dan Planning Poker, Anda dapat meningkatkan akurasi estimasi Anda. Estimasi ulang secara teratur dan menggunakan alat untuk pelacakan waktu dan manajemen sumber daya semakin meningkatkan keandalan jadwal dan anggaran proyek Anda. Dengan mengikuti praktik-praktik ini, Anda dapat mengatasi tantangan perkiraan yang tidak akurat dan memastikan hasil proyek yang lebih baik.
Gunakan teknik estimasi Planning Poker dengan mudah
Lihat alasan mengapa perangkat lunak manajemen sumber daya kami dipilih oleh manajer proyek dari Hill-Knowlton atau Stormind Games
Kalender sumber daya (atau kalender manajemen proyek, atau kalender perencanaan proyek, perangkat lunak perencanaan sumber daya) memungkinkan Anda merencanakan dan mengelola serta mengalokasikan sumber daya secara lebih efektif dan efisien - terutama jika Microsoft Excel memiliki peran utama dalam...
Apa tujuan akhir dari manajer proyek? Menyelesaikan proyek mereka dengan sukses. Para PM sendiri mengakui bahwa hal ini tidak terlalu sering terjadi: menurut survei Pulse of the Profession terbaru, kurang dari 60% proyek yang diselesaikan dengan baik...
Manajemen kapasitas adalah strategi yang digunakan oleh bisnis untuk memanfaatkan efisiensi produksi dengan sebaik-baiknya sehubungan dengan permintaan layanan atau produk. Tujuan akhir dari manajemen kapasitas adalah untuk: Mengidentifikasi dan...