Faktor yang Harus Dipertimbangkan untuk Manajemen Risiko Perangkat Lunak

Apa faktor risiko yang perlu kita pertimbangkan saat merencanakan proyek perangkat lunak.

• Apakah tim Anda cukup terlatih?
• Apakah tim Anda cukup besar?
• Apakah Anda memiliki kemungkinan jika seseorang meninggalkan proyek, dan bagaimana pengaruhnya terhadap jadwal?
• Apakah tim Anda terlalu besar?
• Apakah mereka memiliki sumber daya yang mereka butuhkan?
• Bisakah pesaing membawa produk ke pasar sebelum proyek Anda selesai?
• Bisakah Anda menangani persyaratan yang diubah?
• Bisakah Anda berurusan dengan proyek menjadi tidak relevan?
• Apakah Anda menerima dukungan dari manajemen senior?
• Apakah Anda memiliki ketergantungan pada pemasok atau kontraktor?
• Apakah Anda melakukan sesuatu di rumah yang tim Anda tidak cukup kompeten?
• Apakah Anda memiliki anggaran yang cukup besar untuk memenuhi perkiraan biaya proyek?
• Bisakah Anda memenuhi biaya proyek yang tidak terduga?
• Dan apa pun yang khusus untuk keadaan Anda :-)

Saya akan menambahkan ke daftar @ Graham:

• Apakah beberapa persyaratan di luar kendali Anda (mis. Undang-undang tentang penghitungan pajak penjualan) dan dapatkah mereka berubah?
• Apakah Anda menggunakan alat untuk pertama kalinya dan seberapa percaya diri Anda bahwa alat itu akan bekerja untuk Anda? (Mungkin merek baru, mis. Azure, atau baru bagi tim Anda)
• Apakah Anda mengandalkan penerimaan umum oleh pengguna produk lain (misalnya menulis aplikasi iPhone berarti Anda mengharapkan pengguna memiliki iPhone, menulis aplikasi BlackBerry berarti Anda mengharapkan pengguna Anda memiliki BlackBerries, dll.)
• Dapatkah Anda mengembalikan / membuat ulang pekerjaan yang hilang atau salah-ubah (tidak hanya kontrol sumber tetapi kontrol versi untuk dokumen, email dari klien, dll)
• Apakah Anda memiliki alat dan proses yang memungkinkan Anda untuk memahami kemajuan, kurangnya kemajuan, dan regresi? Apakah manajemen memahami tonggak sejarah (saya punya proyek di mana pada 10% menyelesaikan manajemen melihat prototipe UI dan percaya pekerjaan itu "hampir selesai" kemudian ditekan untuk cepat-cepat bergegas dari saat itu.)
• Apakah Anda memiliki pengujian (otomatis atau tidak) untuk menunjukkan bahwa serangkaian perubahan tertentu tidak merusak bagian lain dari aplikasi? Tanpa tes semacam itu, dapatkah Anda membuat perubahan signifikan seperti porting ke bahasa atau platform lain?

Saya akan menambahkan yang berikut ini:

• Apakah Anda tahu kebutuhan pelanggan Anda. Jika tidak, sudahkah tim pengumpul persyaratan Anda secara memadai menentukan apa yang diinginkan pelanggan di masa lalu dan cukup responsif untuk memastikan bahwa perubahan disebarkan secepat mungkin ke tim pengembangan? Apakah mereka menambahkan pelapisan emas ke persyaratan?
• Apakah ada produk yang Anda bersaing dengan dan sudahkah Anda menentukan sebelum merancang bagaimana Anda akan bersaing dengan produk ini? Ini sangat penting karena produk yang sudah ada sering keluar dengan aspek "Saya ingin fitur itu juga" yang dapat membuat Anda menyimpang dari rencana awal. Apakah tim / manajemen / target pelanggan Anda dapat dilacak oleh kejadian seperti itu dan apakah Anda memiliki rencana darurat yang disiapkan untuk menangani masalah seperti itu?
• Apakah desain yang diusulkan untuk produk Anda relevan dengan pasar? Setengah jalan Anda tidak ingin menemukan bahwa sementara itu memuaskan kebutuhan pelanggan Anda, ia tidak memiliki aspek penting untuk bersaing di dunia "baru".

Pengembangan Cepat Steve McConnell berisi bab tentang manajemen risiko, dengan daftar panjang risiko yang bermanfaat. Saya telah menggunakannya sebagai titik awal lebih dari sekali.

Apakah Anda memiliki campuran orang yang tepat? Apakah semua pengembang aplikasi Anda pengembang dalam proyek data-sentris? Apakah Anda memerlukan perancang basis data, orang QA, atau spesialis UI alih-alih hanya merekrut orang dengan keahlian yang sama?

Apakah Anda memiliki perangkat keras yang memadai untuk mendukung proyek? Ini terutama benar jika Anda membuat sistem volume tinggi atau jika Anda terlalu murah untuk membeli server pengembangan selain server produksi.

Sudahkah Anda mengatur cadangan dari basis data Anda? Hanya memiliki kode untuk membuat ulang basis data tidak cukup, Anda harus menjaga data juga bahkan pada dev.

Apakah pengembang Anda bekerja dengan kumpulan data kecil dan bukannya satu ukuran yang akan diproduksi? Ini hampir menjamin masalah kinerja produksi karena kueri yang bekerja dengan baik pada kumpulan data kecil seringkali tidak pada kumpulan besar. Saya telah melihat banyak pembaruan produksi gagal yang harus segera dibatalkan karena masalah khusus ini.

Apakah Anda mendefinisikan apa yang harus dilakukan dalam kasus tepi dan apakah Anda mengujinya? Sebagai contoh, saya telah melihat proyek-proyek di mana tidak ada yang pernah mendefinisikan apa yang terjadi apa persetujuan diperlukan dan pemberi persetujuan mengatakan tidak.

Apakah Anda akan dipaksa membuat pilihan desain yang buruk untuk memenuhi tenggat waktu yang tidak masuk akal?

Dalam perencanaan Anda untuk proyek, apakah Anda menganggap orang-orang mengambil liburan dan hari-hari sakit, mendapatkan tugas sebagai juri, mengambil cuti berkabung dll? Anda perlu merencanakan tidak hanya untuk orang-orang yang keluar dari proyek tetapi untuk cuti sehari-hari yang didapat orang.