Tôi có nên bảo đảm hoặc thêm một điều khoản bảo hành vào hợp đồng của mình trong trường hợp phá vỡ mã sự kiện hoặc sự bất thường xảy ra bên ngoài bàn tay của khách hàng hoặc hành động của Thiên Chúa?
Nếu vậy, ngôn ngữ đó nên nói gì?
Tôi có nên bảo đảm hoặc thêm một điều khoản bảo hành vào hợp đồng của mình trong trường hợp phá vỡ mã sự kiện hoặc sự bất thường xảy ra bên ngoài bàn tay của khách hàng hoặc hành động của Thiên Chúa?
Nếu vậy, ngôn ngữ đó nên nói gì?
Câu trả lời:
Trừ khi khách hàng của bạn yêu cầu một số loại bảo lãnh hoặc bảo hành, không nên cung cấp một loại. Nhiều khách hàng sẽ kết thúc việc sử dụng nó để buộc bạn phải phục vụ.
Ngay cả khi họ có nhu cầu, hãy hỏi ý kiến luật sư. Nếu không, bạn đang tự đặt ra cho thảm họa.
Tôi có nên bảo đảm hoặc thêm một điều khoản bảo hành vào hợp đồng của mình trong trường hợp phá vỡ mã sự kiện hoặc sự bất thường xảy ra bên ngoài bàn tay của khách hàng hoặc hành động của Thiên Chúa?
Nếu được yêu cầu đừng nhận công việc. Đây là một tình huống không thể. Không có kết thúc cho danh sách những thứ có thể thay đổi sẽ khiến mã của bạn bị hỏng hoặc không hoạt động.
Trừ khi bạn thích làm việc miễn phí, thì hãy tiếp tục.
Cách tiêu chuẩn để đáp ứng điều này là thêm một điều khoản hỗ trợ hoặc bảo trì - "10 giờ làm việc đầu tiên được bao gồm miễn phí, phần còn lại có sẵn theo tỷ lệ sau:".
Tôi đã ủng hộ "đừng làm" của Adam, nhưng việc bảo hành như vậy cho một sản phẩm phần mềm thương mại có thể nhận được nhiều sự quan tâm của khách hàng. Nó cũng sẽ cho thấy bạn có cojones rất lớn so với phần còn lại của ngành công nghiệp. :-)
Tôi có thể xem xét việc cung cấp bảo hành trong các trường hợp sau đây:
Trong trường hợp đó, tôi có thể bảo hành một cái gì đó như: "Trong khoảng thời gian một năm kể từ ngày mua, chúng tôi đảm bảo rằng nếu phần mềm không chạy đáng kể như được ghi trong hướng dẫn sử dụng, chúng tôi sẽ sửa lỗi và phát hành miễn phí cập nhật. "
Điều đó không có vẻ giống như một sự bảo đảm, nhưng nó vượt xa hầu hết các phần mềm thương mại, đảm bảo với khách hàng rằng bạn sẽ sửa lỗi và từ "đáng kể" để lại đủ chỗ ngọ nguậy mà bạn sẽ không phá vỡ.
Nếu đó là hợp đồng lập trình cho người khác, hãy quên nó đi. Tôi đã từng gặp một tình huống tương tự như vậy, chuyển một chương trình Windows sang Mac và mất hàng chục ngàn đô la để sửa các "lỗi" thực sự bị ẩn trong các phiên bản Windows mà khách hàng không thể đề cập trước khi chúng tôi ký hợp đồng , mặc dù chúng tôi đã nhiều lần yêu cầu thông số kỹ thuật. Kinh nghiệm đó là một trong những lý do chính khiến tôi bỏ việc làm hợp đồng giá cố định.
Việc bảo hành bao gồm sửa lỗi trong một khoảng thời gian cụ thể sau khi kết thúc dự án là điều phổ biến (giả sử 3-6 tháng). Điều này nói với khách hàng rằng bạn đứng đằng sau mã của bạn và thật lòng mà nói bạn phải có một số trách nhiệm đối với các vấn đề mà bạn cung cấp với mã của mình.
Những gì chúng ta thường làm trong các dự án của mình là cung cấp SLA (thỏa thuận cấp độ dịch vụ) xác định lỗi là gì và thời gian biểu để sửa chúng theo mức độ nghiêm trọng của chúng. Ví dụ, các vấn đề quan trọng trên một dự án trực tiếp nên được giải quyết (ít nhất là cố gắng) trong vòng 1 giờ kể từ khi nhận được báo cáo. Các vấn đề về thị giác và các lỗi nhỏ sẽ được giải quyết trong vòng 48 giờ.
Điều rất quan trọng là phải có định nghĩa rõ ràng về lỗi là gì - vì khách hàng sẽ thường cố gắng làm việc trong các tính năng mới dưới dạng báo cáo lỗi (đôi khi vô tình). Những định nghĩa đó luôn có phần mở để giải thích, vì vậy bạn cần chỉ định một trọng tài viên (thường là người có thẩm quyền trong ngôn ngữ / nền tảng phát triển) có thể phân xử các bất đồng.
Từ ngữ của hợp đồng sẽ phải nêu những điều tương tự như sau:
Chỉ là một vài tôi có thể nghĩ ra.