Dalam pengembangan perangkat lunak freelance, hukuman seperti apa yang harus dimiliki perusahaan ketika mereka melewati tenggat waktu? [Tutup]


12

Saya sedang berbicara dengan co-developer.

Dia memiliki klien yang ingin memastikan bahwa dia memberikan tepat waktu. Klien menginginkan akibat dari tenggat waktu yang terlewat.

Meskipun saya tidak melakukan pekerjaan lepas, saya tidak bisa memberikan jawaban.

Jadi, pertanyaan saya adalah:

Apa dampak yang Anda (freelancer) sepakati dengan klien Anda jika Anda kehilangan tenggat waktu pada hasil kerja Anda (selain dipecat)?


2
Dia akan bodoh menerima hukuman apa pun, setidaknya tanpa klausul keluar berdasarkan perubahan persyaratan. Estimasi tugas sangat tidak akurat pada saat-saat terbaik, sebelum mempertimbangkan manajemen perubahan akun. Pada dasarnya Jalankan
Matt D

4
Jadi klien akan memiliki kepentingan finansial untuk membuat Anda melewatkan tenggat waktu? Kedengarannya bukan ide yang bagus. Ini hanya akan masuk akal jika klien juga mengalami kerugian finansial yang berat ketika Anda terlambat (seperti pada contoh MainMa).
Doc Brown

2
Ini sepertinya bisa diterima oleh saya. Saya cukup terkejut dengan komentarnya. Anda mengharapkan orang membayar untuk pekerjaan, tanpa batas waktu dan tidak ada insentif untuk memenuhi batas waktu? "Estimasi tugas sangat tidak akurat" - tidak harus seperti itu.
NimChimpsky

@DocBrown klien mungkin memiliki kepentingan finansial yang jauh lebih besar dalam memenuhi tenggat waktu, karenanya membayar pekerjaan dengan tenggat waktu. Saya menemukan programmer kadang tidak suka tenggat waktu dan struktur luar biasa. Bayangkan mendapatkan dapur baru dipasang dan toko mengatakan oooooo tidak, kami tidak bisa memberi tahu Anda kapan itu akan selesai, hanya akan menagih Anda per jam. Saya akan lari satu mil dari itu. Pemrograman tidak berbeda secara kualitatif dengan proyek lain mana pun.
NimChimpsky

5
Jika Anda mendapatkan dapur baru yang pas, Anda akan dikutip untuk build sesuai spesifikasi. Jika Anda mulai mengubah permukaan pemotongan, ubin, keran dan bahan bak cuci Anda akan dikenakan biaya tambahan untuk kedua bahan yang terbuang, dan waktu yang dihabiskan. Sangat mudah untuk memahami mengapa Anda ditagih dalam hal ini, ada hubungan fisik. Mengubah persyaratan perangkat lunak sering kali tidak disertai dengan pemahaman yang sama, dan kontrak apa pun yang mengharuskan Anda untuk memberikan X oleh Y di mana X tidak dipaku persis meminta masalah. Segala sesuatunya akan berubah, karena tidak dapat menjelaskan hal itu bodoh.
Matt D

Jawaban:


25

Salah satu yang paling efektif: penalti pada hari keterlambatan. Ini juga yang dilakukan untuk proyek-proyek besar, hukumannya kadang-kadang ribuan dolar per hari.

Jika tenggat waktu yang tepat penting (misalnya jika seseorang mengembangkan untuk Olimpiade aplikasi web yang akan menangani siaran acara di 2014, batas waktu akan menjadi awal Olimpiade di 2014), maka ukuran efektifnya bisa berupa di sebuah kasus ketika proyek terlambat, perusahaan tidak dibayar sama sekali, dan juga harus membayar penalti.

Jika tindakan drastis seperti itu tidak tepat, maka satu-satunya fakta bahwa pelanggan yang membayar akan pergi jika proyek terlambat dapat melakukan trik.

Catatan untuk pelanggan:

  1. Banyak penundaan adalah kesalahan pelanggan itu sendiri. Penyebabnya bisa beragam:

    • Bukan SRS, melainkan dua paragraf yang menggambarkan dengan buruk apa yang pelanggan bayangkan sebagai kebutuhannya (dan tentu saja, pelanggan tidak ingin membayar untuk pengumpulan persyaratan, mengingat langkah ini kehilangan waktu).

    • Datang dua minggu sebelum batas waktu akhir dan mengatakan bahwa tidak masalah bahwa proyek itu dilakukan di Jawa sampai sekarang dan menggunakan Oracle: sangat penting untuk itu harus ditulis ulang dalam Python dan menggunakan MySQL, karena pelanggan telah membaca majalah kemarin mengatakan bahwa teknologi itu adalah masa depan.

    • Hadir dengan serangkaian persyaratan baru di setiap pertemuan. Poin bonus ketika persyaratan tersebut bertentangan hampir setiap persyaratan yang diberikan sampai sekarang.

  2. Komunikasi yang baik sangat penting untuk proyek yang baik.

    Banyak penundaan lain disebabkan oleh kurangnya komunikasi. Praktek di mana pelanggan tidak memiliki komunikasi apa pun selama berbulan-bulan dengan perusahaan dan berharap untuk dihubungi hanya setelah produk selesai dan dipoles mengundang bencana.

  3. Kau mendapatkan apa yang kau bayar.

    Ada prosedur khusus yang membantu menjaga proyek tetap terorganisir, dan sebenarnya, pemrograman hanya membutuhkan 10 hingga 15% waktu untuk proyek besar dan 15% hingga 20% dari waktu untuk proyek menengah. Proyek-proyek itu juga harus dilakukan oleh orang-orang yang tahu apa yang mereka lakukan.

    Dalam praktiknya, pelanggan tidak bersedia membayar $ 800 / hari seorang analis yang akan membuat desain arsitektur dan perangkat lunak, dan mereka juga tidak mau membayar untuk langkah-langkah lain. Seorang programmer Albania pemula yang senang bekerja untuk $ 50 / hari tampaknya jauh lebih menguntungkan.

    Jangan mengeluh bahwa proyek ini adalah bencana ketika Anda hanya siap membayar untuk proyek bencana.

  4. Jangan menegosiasikan waktu yang diperlukan untuk melakukan pekerjaan itu.

    Saya sering mengalami diskusi seperti itu:

    Pengembang: dengan persyaratan, saya bisa mengirimkannya dalam empat bulan.
    Pelanggan: tidak mungkin. Proyek harus dilakukan dalam dua bulan.
    Pengembang: baik, kecuali Anda memotong beberapa fitur ...
    Pelanggan: Saya tidak bisa! Semua fitur diperlukan. Mengapa Anda tidak bisa melakukan pekerjaan dalam dua bulan? Saya menghubungi seorang programmer India, seorang teman saya, dia dapat mengirimkannya dalam satu setengah bulan, dan meminta hanya setengah dari harganya!

    Negosiasi waktu adalah resep untuk bencana.

  5. Ketahui prioritas Anda.

    Memperhatikan aturan 90% yang dilakukan. Ketika proyek dikelola secara tidak benar, tidak biasa melihat pengembang mengatakan bahwa mereka telah melakukan 90% proyek sebulan setelah memulai proyek. Lalu, sebulan kemudian, masih 90%. Dan sebulan kemudian.

    Ini dapat memiliki dua penyebab:

    • Ketika proyek tidak dilakukan dengan benar, yaitu 100% dari waktu didedikasikan untuk pemrograman, yang menyisakan 0% untuk pengumpulan persyaratan, arsitektur, desain dan pengujian, yang terjadi adalah bahwa programmer tidak tahu tentang pekerjaan yang harus dilakukan, dan mereka menemukan tugas-tugas baru selama seumur hidup proyek. Mempersiapkan proyek akan membantu memiliki pemahaman yang lebih besar tentang semua tugas yang harus diselesaikan.

    • Ketika pelanggan sedang tergesa-gesa, tidak jarang bagi beberapa perusahaan untuk memberikan omong kosong cepat, kemudian menghabiskan banyak waktu untuk menyelesaikan bug. Beberapa perusahaan hanya bekerja seperti itu, yang membantu mereka tetap kompetitif dan mengatakan bahwa mereka menyelesaikan proyek yang diberikan dalam tiga minggu, bahkan jika kemudian, mereka menghabiskan tiga tahun menyelesaikan kekacauan.

    Dengan meluruskan prioritas dan mengharuskan proyek dilakukan dengan benar membantu menghilangkan perusahaan-perusahaan tersebut dari daftar kandidat.


3
"Jangan mengeluh bahwa proyek ini adalah bencana ketika kamu hanya siap untuk membayar proyek bencana." Bisakah saya menggunakannya? Ini adalah postingan bagus, dan dengan baik merangkum risiko dari kedua belah pihak.
Matt D

+1 Poin yang sangat bagus. Juga, senang membaca :)
Radu Murzea

5
@MattD: jawaban di Stack Exchange dilisensikan di bawah Creative Commons Attribution-ShareAlike 3.0 Unported, jadi ya, Anda bisa. Juga, jangan ragu untuk membaca posting terkait di blog saya: Menghitung waktu dan biaya: Mengapa kita selalu salah? , serta jawaban untuk pertanyaan saya di sini: programmers.stackexchange.com/q/158640/6605
Arseni Mourzenko

Mengapa tidak ada bagian 4, 5, 6 dll untuk posting blog itu?
Radu Murzea
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.