Mengukur harga untuk kode sumber dan produk perangkat lunak

Saya akan melakukan proyek. Ini mengharuskan saya untuk menulis kode, dan banyak lagi. Persyaratan klien adalah menyerahkan semua kode sumber pada akhir proyek.

Pertanyaan saya adalah: Bagaimana cara saya menghitung harga untuk kode sumber dan produk perangkat lunak? Apakah ada metrik yang diikuti seseorang untuk menentukan harga? Bagaimana saya mengukur produk perangkat lunak?

Info tambahan: Aplikasi harus dijalankan di mana saja, di OS apa pun, termasuk tablet (iPad, Galaxy tab, dll.), Ponsel Cerdas (iPhone, ponsel Android, dll.) Dan juga di web. (Sekarang, bayangkan berapa banyak kode ini) .

Anda tidak akan pernah tahu harga yang pasti atau hampir pasti, karena itu tergantung pada banyak faktor. Contoh:

Studi kasus

Anda mendapat permintaan untuk situs web kecil berdasarkan WordPress. Satu-satunya hal yang harus Anda lakukan: bekerja dengan desainer Anda untuk membuat grafik yang menarik, kemudian membuat situs web itu sendiri (tidak ada yang sangat teknis, hanya satu set plugin untuk ditambahkan ke WordPress), dan kemudian gunakan. Pekerjaannya sangat mudah, Anda mengutipnya $ 600.

Desainer Anda membuat konsep pertama. Pelanggan menjelaskan bahwa dia merasa itu tidak menarik sama sekali. Hal yang sama berlaku untuk draft kedua, ketiga dan keempat. Akhirnya, setelah dua minggu bekerja keras, sang desainer akhirnya mendapatkan konsep yang diterima oleh pelanggan.

Tapi sayangnya perancang ditabrak bus dan satu-satunya yang Anda dapatkan adalah JPEG yang ia kirimkan kepada Anda, tetapi bukan PSD asli, jadi Anda harus memulai dari awal dengan perancang baru. Akhirnya, Anda mendapatkan gambar dan memulai pekerjaan Anda.

Kejutan: Anda telah menemukan bahwa plugin A tidak kompatibel dengan plugin B, bahwa plugin C tidak berfungsi seperti yang diharapkan, dan bahwa plugin D tidak dapat diinstal pada WordPress versi terbaru, sedangkan plugin A hanya dapat diinstal pada versi terbaru ini. Sekarang Anda harus melakukan banyak pengkodean PHP dengan tangan, dan karena Anda adalah seorang pengembang Python dan tidak pernah menulis satu baris kode pun dalam PHP, itu bukan tugas yang paling mudah.

Sementara itu, pelanggan mulai mengirimi Anda email-email menakutkan, menanyakan mengapa pekerjaan itu belum selesai, sedangkan tenggat waktu seminggu yang lalu. Anda akhirnya menyelesaikan pengkodean PHP, dan semuanya bekerja dengan baik di mesin Anda. Pelanggan itu senang.

Kemudian Anda mulai menyebarkan situs web ke server hosting untuk menemukan bahwa tidak hanya situs web gagal dengan beberapa kesalahan samar, tetapi juga perusahaan hosting tidak mendukung fitur PHP yang telah Anda gunakan banyak dalam kode Anda.

Akhirnya, setelah menghabiskan lebih dari $ 3.000 untuk proyek ini, Anda memiliki situs web dan berjalan. Pelanggan marah karena tenggat waktu dan karena "tidak ada yang berfungsi seperti yang diharapkan dengan Anda". Apakah Anda akan meminta $ 600? $ 3.000?

Mengapa itu terjadi?

Apa yang saya ilustrasikan dalam contoh ini terjadi jauh lebih sering daripada yang Anda yakini. Mengapa? Karena ada terlalu banyak variabel yang tidak dapat Anda prediksi dan yang meningkatkan risiko. Di sini, risikonya meningkat dengan:

• Spesifikasi yang tidak jelas terkait dengan desain visual,
• Kematian sang desainer,
• Ketidakcocokan plugin yang Anda pilih,
• Dukungan buruk dari plugin yang Anda pilih,
• Fakta bahwa Anda belum pernah menggunakan PHP sebelumnya,
• Perbedaan antara lingkungan pengembangan dan lingkungan produksi dan tidak adanya pementasan.

Seseorang dapat memecahkan masalah itu dengan pendekatan spesifik:

• Persyaratan fungsional dan non-fungsional yang jelas dan tepat,
• Manajemen skenario hit-by-a-bus (yaitu perancang harus berbagi setiap dokumen dengan Anda sehingga ia bisa mati setiap saat tanpa membahayakan proyek),
• Pengetahuan sebelumnya tentang alat dan bahasa yang harus Anda gunakan (yang membutuhkan banyak pekerjaan),
• Pementasan, pengujian intensif, dll.

Satu-satunya masalah adalah bahwa dengan pendekatan ini, Anda harus memberi tahu pelanggan Anda bahwa ia akan membayar setidaknya $ 5.000, karena sebenarnya itu adalah harga persyaratan, spesifikasi, desain, pengujian, dll. Peluang bagi pelanggan ini untuk menerima kutipan Anda sangat rendah.

Jadi tidak ada yang bisa dilakukan?

Jika Anda tidak dapat memberikan harga yang sangat tepat, Anda masih dapat memberikan perkiraan, yang memperhitungkan setiap bagian pekerjaan yang harus dilakukan secara terpisah, dengan indeks risiko yang terpengaruh untuk setiap bagian. Semakin tinggi risiko yang dapat diprediksi, semakin tinggi pula harganya.

Anda memiliki dua cara untuk melakukan itu:

1. Cara Watefally

Jika Anda bekerja pada proyek yang sesuai dengan Waterfall / V-Model, ini dapat bekerja:

1. Daftar persyaratan fungsional dan non-fungsional suatu proyek. Dapatkan dokumen ditandatangani oleh pelanggan, dengan cara yang sama ia menandatangani kontrak.

2. Setelah Anda mendapatkan dokumen ini, Anda sudah memiliki:

   • Harga yang telah Anda habiskan untuk mengumpulkan persyaratan dan membuat dokumen ini. Ini mungkin mewakili jumlah uang yang penting, karena dokumen-dokumen itu dapat bervariasi dari dua puluh hingga seratus halaman untuk proyek biasa, dan bisa ratusan atau ribuan halaman untuk proyek besar.

   • Pemahaman yang jelas, tepat dan lengkap tentang produk yang Anda minta lakukan.

3. Ikuti langkah demi langkah tim Anda, analisis setiap persyaratan, dan evaluasi:

   • Harga rata-rata dari bagian proyek ini,

   • Harga maksimum tanpa memperhitungkan risiko,

   • Indeks risiko.

   Ketiganya akan diperhitungkan untuk menentukan harga yang akan Anda berikan kepada pelanggan.

4. Aset risiko yang tidak tergantung pada persyaratan tertentu, tetapi lebih pada kompatibilitas antara persyaratan atau pada sistem secara umum.

Kelebihan pendekatan waterfally: pelanggan mendapatkan harga yang cukup tepat, mengingat Anda memiliki visi yang sangat jelas tentang pekerjaan yang harus dilakukan dan risiko yang mungkin timbul.

Kontra dari pendekatan waterfally: Anda harus menulis dokumen 200 halaman sebelum memberikan harga. Bagaimana jika pelanggan membatalkan proyek sementara, atau pergi ke Anda secara bersamaan? Seluruh proses juga sangat berat dan persyaratannya tidak dapat diubah kemudian.

2. Cara tangkas

Jika Anda bekerja pada proyek yang sesuai dengan Scrum atau model gesit lainnya:

• baik tidak memberikan harga keseluruhan proyek, melainkan harga setiap komponen,
• atau Anda dapat menunjukkan harga keseluruhan yang sangat perkiraan di awal, dan kemudian memberikan yang lebih dan lebih tepat.

Dalam kedua kasus, Anda harus memiliki kepercayaan yang kuat antara Anda dan pelanggan, atau memiliki orang-orang hebat di bagian penjualan. Jika tidak,

• dalam kasus pertama, orang tersebut akan percaya bahwa Anda hanya mencuri uangnya meminta jumlah kecil berulang kali, dan ini tidak akan pernah berakhir,

• dalam kasus kedua, orang tersebut tidak akan mengerti mengapa Anda mengubah harga setiap saat, terutama jika harganya naik sebagian besar waktu.

Pendekatan Kelebihan Agile: pelanggan dapat membatalkan kapan saja. Juga, jika dia membatalkan pada tahap awal, dia masih memiliki beberapa kode sumber yang berfungsi.

Kontra pendekatan Agile: harga terlalu tidak tepat atau bahkan tidak diberikan. Sebagian besar pelanggan tidak mau berbisnis dengan Anda jika Anda tidak memberi tahu mereka berapa yang harus mereka bayar.

Jangan menerima sebuah proyek ketika itu tidak jelas baik hasil maupun uang yang harus dibayar oleh klien. Saya hanya melakukan hal berikut:

• Munculkan langkah-langkah dan pembayaran yang perlu dilakukan klien.
• Ketika langkah sebelumnya dilakukan dan dibayar penuh dan klien senang pindah ke langkah berikutnya.

Untuk metode pembayaran, pilih pembayaran berdasarkan fitur. Jadi jika klien memiliki kesempatan untuk menjatuhkan fitur-fitur jika dia tidak dapat membayar seluruh proyek.

Dibayar berdasarkan garis kode (LOC) adalah hal yang bodoh. Karena LOC tidak berarti apa-apa !. Jadilah pandai menulis kode dan biaya yang baik berdasarkan fitur !.

Semoga berhasil,

Jangan terima harga tetap untuk komitmen terbuka. Anda akan kacau setiap kali jika melakukannya.