Siapa yang harus membayar perbaikan / bug? [Tutup]


33

Jadi saya baru saja mulai lepas baik dalam pengembangan desktop / web dan klien ini yang sudah menerima pekerjaan saya, dan membayar saya terus datang kepada saya setiap kali dia menemukan bug dll. Dan saya telah menemukan diri saya menghabiskan lebih banyak waktu daripada yang saya pikir memperbaikinya untuk bebas. Apakah ini baik-baik saja, atau haruskah saya mulai mengenakan biaya dukungan?

Mana cara terbaik untuk menangani perbaikan pada pekerjaan yang seharusnya diterima dan diselesaikan?


5
Untuk bug serius, biasanya ada 'neraka yang harus dibayar', jadi saya kira neraka membayar untuk mereka.
Tim Post

Apa yang Anda maksud dengan "bug dll"? Ada perbedaan antara bug dan pekerjaan lebih lanjut yang tidak melibatkan bug.
David Thornley

Maksud saya perbaikan bug dan cacat bukan fitur tambahan atau pekerjaan lebih lanjut
Agush

Saya juga merujuk pada hal-hal yang bekerja di browser, tetapi istirahat di versi lain atau browser yang tidak jelas. (dalam pengembangan web)
Agush

Lagi: jika kontrak Anda tidak mencantumkan versi browser ini yang didukung oleh Anda, itu bukan tanggung jawab Anda.
Mchl

Jawaban:


42

Bagian dari kontrak Anda harus menggambarkan tes penerimaan yaitu tes yang akan dilakukan klien dan aplikasi Anda harus lulus untuk memenuhi kontrak. Apa pun yang tidak dicakup oleh tes ini adalah tanggung jawab klien. Apa pun yang ditanggung oleh mereka adalah milik Anda.

Karena tidak mungkin (terutama untuk klien non-teknis) untuk melihat semua masalah yang mungkin terjadi, Anda harus menambahkan klausa yang menentukan periode pada kontak Anda, ketika Anda akan memperbaiki masalah baru sebagai bagian dari kontrak. Setelah itu, Anda harus menawarkan hanya dukungan berbayar.


3
Saya merasa mungkin sudah terlambat untuk klien khusus ini, tetapi ini adalah saran yang bagus untuk masa depan.
Dean Harding

1
Bahkan dengan kliennya saat ini, Agush dapat menyetujui serangkaian tes penerimaan. Penting untuk menjelaskan kepada klien, bahwa menyetujui tes semacam itu akan menghasilkan pengiriman aplikasi fungsional yang lebih cepat. Jika klien masuk akal, mereka akan setuju.
Mchl

Tepat. Apa yang akan Anda lakukan perlu dinyatakan dalam kontrak atau perjanjian sebelumnya untuk kepuasan semua orang. Setelah itu sudah terlambat. Setelah proyek dikirim jika Anda dan pelanggan tidak setuju, Anda harus menemukan cara untuk kompromi mengenai hal itu dan ini bisa rumit.
glenatron

10

Tergantung.

Dalam contoh pertama Anda harus membayar karena dapat dikatakan bahwa pekerjaan itu tidak lengkap.

Kemudian pelanggan harus membayar untuk dukungan yang berkelanjutan.

Namun, masalahnya adalah dalam menentukan di mana batas itu dan apa yang merupakan bug dan apa fitur baru. Memiliki persyaratan dan / atau tes penerimaan jauh untuk mendefinisikan ini.

Anda benar-benar harus menyiapkan semua ini sebelum Anda menyelesaikan pekerjaan, tetapi jika Anda belum melakukannya, mungkin sekarang saatnya untuk mengatakan - "Saya akan mendukung ini secara gratis selama N hari / minggu ke depan, tetapi setelah itu kami perlu membahas kontrak dukungan "(perhatikan penekanan saya pada" kami ").

Setelah mengatakan semua itu, ada kalanya Anda perlu memperbaiki bug secara gratis dan menerima pukulan. Jika tidak ada yang lain itu membangun niat baik.


1
Dari tempat Anda sekarang, ini saran yang bagus. Anda mungkin harus terus memperbaiki bug untuk pelanggan ini untuk sementara demi kepentingan niat baik dan reputasi yang sangat berarti jika Anda baru memulai. Pertimbangkan ini harga untuk mempelajari pelajaran tentang menetapkan apa yang ada dan keluar dari ruang lingkup untuk dukungan sebagai bagian dari kontrak Anda ...
glenatron

10

Semua jawaban yang diberikan di atas baik. Namun, saya akan menambahkan beberapa poin untuk dipertimbangkan:

  • Apakah klien berharga bagi Anda? Terkadang ada gunanya pergi beberapa meter ekstra untuk membuat klien bahagia jika Anda merasa mereka berharga bagi Anda dan akan membawa Anda lebih banyak pekerjaan di masa depan. Anda perlu menemukan keseimbangan antara menjadi ketat dan fleksibel dan ini mungkin berbeda untuk setiap klien. Tidak ada gunanya kehilangan pekerjaan di masa depan hanya karena Anda bersikeras bahwa bug yang mudah diperbaiki jatuh di luar jangkauan. Di sisi lain, Anda tidak ingin membiarkan klien menguasai Anda. Ini keseimbangan yang halus!

  • Apakah bug itu sesuatu yang bisa dengan mudah dilewatkan dalam pengujian pengguna? Sebagai contoh, ambil bug terkait tanggal yang hanya berlaku ketika tahun tertentu dimasukkan (pikirkan bug Millennium dll). Seorang klien tidak dapat secara wajar diharapkan untuk menemukan ini selama pengujian karena itu tanggung jawab ada pada Anda untuk memperbaikinya.


Benar sekali saya akhirnya memperbaikinya, karena kehilangan klien tidak sebanding dengan masalahnya, untuk saat ini.
Agush

6

Ketika saya lepas, perjanjian pelanggan dasar saya mendefinisikan suatu kondisi yang disebut "penerimaan", yang diperlukan sebelum saya menempatkan proyek langsung ke publik. Pada saat penerimaan, mulai ada periode 30 hari yang saya sebut "dukungan dan dukungan". Setelah periode 30 hari itu, pekerjaan yang sedang berlangsung pada proyek dapat ditagih setiap jam.

Jika Anda memiliki hubungan yang baik dengan klien ini, berhati-hatilah dengan mereka tentang betapa tidak praktisnya situasi saat ini bagi Anda, dan usulkan tarif per jam yang adil untuk pemeliharaan dan dukungan yang berkelanjutan. Orang-orang kadang berpikir bahwa membeli perangkat lunak khusus adalah seperti membeli sandwich atau sesuatu, seperti begitu itu dibangun selesai. Hanya saja tidak seperti itu.


Terima kasih ini cara yang baik untuk menanganinya. Periode dukungan setelah penerimaan, dan setelah itu, mereka sendiri.
Agush

2

Umumnya Anda dapat mencari dukungan gratis untuk jumlah hari yang tetap setelah Anda mengirimkan aplikasi. Tentu saja dukungan gratis seumur hidup tidak mungkin / tidak dapat diterima.

Pastikan bug yang diangkat adalah BUG dan bukan perubahan ke fitur yang ada. Untuk setiap perubahan fitur, Anda harus mengenakan biaya.


2

Jika dia mengujinya dan menandatanganinya, Anda bisa membantah bahwa ia harus membayar.

Jika Anda bangga dan menghargai pekerjaan Anda, Anda bisa membantah bahwa Anda akan memperbaiki kodenya. Belajar dari pengalaman dan membangun kode yang lebih baik lain kali, lebih efisien. Atau faktor dalam lebih banyak laba untuk menutupi perbaikan bug.

Jika program melakukan sesuatu yang tidak diinginkan atau tidak terduga diberikan masukan, maka itu adalah bug, dan harus diperbaiki.

Anda bisa mengutip untuk biaya dukungan di muka sebagai tambahan untuk pekerjaan pengembangan awal.


2

Dalam kontrak Anda, tentukan tarif per jam dan catat waktu Anda. Saat Anda memberi harga kepada klien Anda, tentukan bahwa ini adalah perkiraan dan hasil yang sebenarnya mungkin kurang atau lebih.

Jaga agar klien tetap mengetahui perkembangannya, dan ketika dia mau tidak mau memberikan saran, Anda bisa langsung memberi tahu dia waktu yang diperlukan (jika perubahan di luar spesifikasi asli) dan dia dapat memutuskan apakah perubahan itu sepadan dengan uang. Karenanya hanya perubahan yang penting baginya yang akan ditambahkan.

Saya pribadi akan menutupi bug yang diterima dan tidak dapat diterima (dukungan berbayar vs dukungan gratis) dalam kontrak, dan dengan cara itu Anda setidaknya memiliki sesuatu secara tertulis dari awal. Dia pasti akan bertanya-tanya mengapa Anda perlu klausa itu, jadi dimuka dan jelaskan bahwa jika pembaruan OS baru keluar yang merusak sesuatu, itu bukan dukungan gratis. Namun, bug dalam kode Anda sesuai dengan spesifikasi asli pada platform yang ditentukan akan dibahas.

Namun, saya harus menyebutkan saya hanya melakukan pekerjaan IT lepas daripada pemrograman. Ini mungkin dapat menakuti klien, tetapi pastikan pekerjaan Anda menjual dirinya sendiri, menjadi lebih profesional, ramah, dan membantu daripada yang lain, dan sampaikan dengan alasan Anda memiliki kontrak yang lebih ketat.

Selain itu, klien yang tidak akan menerima klausa itu kemungkinan besar adalah klien yang buruk.

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.