Menulis perangkat lunak berdasarkan konsultasi seringkali dapat menjadi kerugian bagi pengembang atau klien atau keduanya. Ada terlalu banyak hal yang bisa salah, dan yang akhirnya menyebabkan hilangnya waktu dan uang. Aturan 15% yang kami buat dimaksudkan untuk menciptakan situasi yang saling menguntungkan bagi kedua belah pihak.
Klien umumnya mendapatkan apa yang mereka inginkan, dan toko-toko pengembangan menghasilkan keuntungan yang adil. Solusi yang sempurna, tetapi sejauh ini tampaknya bekerja untuk kita.
Ini mungkin mengejutkan bagi sebagian orang, tetapi kami menghasilkan sedikit uang dengan menjual lisensi perangkat lunak. Sebagian besar pendapatan kami datang melalui layanan konsultasi menulis kode untuk disewa. Setelah melakukan ini selama beberapa tahun, kami telah belajar beberapa pelajaran sulit. Pada beberapa proyek, pelajarannya sangat sulit sehingga kami benar-benar kehilangan uang. Beberapa bulan yang lalu saya mengumpulkan beberapa jenis dokumen manifesto dimaksudkan untuk mengatasi kesulitan yang kami hadapi dalam mengembangkan perangkat lunak untuk klien. Tujuannya senang mengatakan bahwa itu membuat perbedaan yang nyata. Harapan saya adalah bahwa entri rawa ini akan dibaca oleh orang lain yang mengembangkan perangkat lunak berdasarkan konsultasi, sehingga mereka dapat mempelajari pelajaran ini dengan cara yang mudah daripada cara kita mempelajarinya. Apa yang mengikuti dalam artikel ini adalah ringkasan dari salah satu prinsip utama yang sekarang kita ikuti dalam mengembangkan perangkat lunak aturan 15%. Jika Anda suka, Anda dipersilakan untuk membaca dokumen lengkap Pendekatan Kami untuk Pengembangan Perangkat Lunak. Untuk yang tidak sabar, aturan 15% berlaku seperti ini sebelum melakukan proyek pengembangan, kami membuat pernyataan kerja (yang bertindak sebagai kontrak dan spesifikasi) yang menguraikan apa yang dilakukan dengan baik, berapa jam yang dibutuhkan, dan berapa banyak yang dibutuhkan biaya klien. Sebagai bagian dari kontrak, kami berkomitmen untuk berinvestasi hingga jumlah waktu yang dijelaskan dalam dokumen plus 15%. Artinya, jika pernyataan kerja mengatakan bahwa proyek akan membutuhkan waktu 100 jam untuk kami selesaikan, kami akan menghabiskan waktu hingga 115 jam (tetapi tidak lebih). Tentang di mana-hutan dan mengapa-melemparkan tentang bagaimana ini bekerja, baca terus. Mereka yang telah mengembangkan perangkat lunak untuk disewa tahu bahwa produk akhirnya hampir tidak pernah berakhir persis seperti yang dibayangkan klien. Ada beberapa tweak yang perlu dibuat (yang mungkin atau mungkin tidak pernah dibahas di muka) untuk mendapatkan hal yang setidaknya menyerupai apa yang ada dalam pikiran klien. Dan, ya, ini bisa terjadi bahkan jika Anda menghabiskan berjam-jam menyempurnakan spesifikasi untuk mencerminkan keinginan klien. Selain itu, masalah teknis dapat muncul yang tidak diantisipasi oleh tim pemrograman. Secara teori, semakin baik tim pemrograman semakin kecil kemungkinannya, tetapi tidak selalu berakhir seperti itu (sistem operasi Microsoft Vista adalah contoh yang bagus). Kedua faktor ini, antara lain, setara dengan risiko yang melekat pada proyek. Sesuatu tidak akan berjalan dengan benar, dan itu hampir selalu berarti seseorang membayar atau kehilangan lebih banyak uang daripada yang diperkirakan sebelumnya. Pertanyaannya adalah siapa yang harus bertanggung jawab untuk menghitung dolar ekstra itu? Hingga relatif baru-baru ini, kami akan memikul hampir semua risiko dalam proyek kami. Jika aplikasi tidak melakukan apa yang ada dalam pikiran klien, atau jika masalah teknis yang tidak terduga muncul, umumnya keluar dari kantong kami Untuk sebagian besar itu tidak bisa menjadi masalah besar, tetapi selalu tampaknya memiliki setidaknya beberapa efek ( kasus ekstrim jelas ketika kita kehilangan uang pada suatu proyek). Ini sepertinya tidak adil, bukan? Risiko yang melekat pada proyek tidak selalu merupakan kesalahan salah satu pihak. Hanya di sana. Kami tidak meletakkannya di sana, dan klien juga tidak. Karena itu, seharusnya tidak demikian halnya jika satu pihak memikul semuanya.
Bagaimana Perangkat Lunak Dibuat