Điều khoản bảo hành hoặc bảo hành cho việc phá mã


9

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ì?


2
hậu quả của lỗi mã là gì? phần mềm, ngay cả phần mềm thương mại lớn, thường được cung cấp "nguyên trạng" không có bảo hành - thực tế, trong hầu hết tất cả các phần mềm thu nhỏ, EULA sẽ không chịu bất kỳ trách nhiệm nào đối với việc sử dụng phần mềm. Vì vậy, tôi khuyên bạn nên đi theo con đường đó. Nếu không, bạn sẽ để mình bị kiện vì tất cả những gì bạn có và sẽ kiếm được vì phần mềm của bạn đã đưa ra một thông báo lỗi ngăn bà ngoại nhìn thấy tin nhắn facebook của con cháu mình, và chết vì đau khổ khi được thông báo rằng đã xảy ra sự cố.
TZHX

1
... Bạn sẽ cần cung cấp thêm thông tin về tình huống cụ thể trước khi mọi người có thể đưa ra câu trả lời có căn cứ, nhưng thông thường trong kịch bản nhà thầu, một phần của hợp đồng sẽ liên quan đến việc khách hàng "ký tắt" trên phần mềm trước khi trả số tiền cuối cùng . Bạn thường sẽ được yêu cầu thực hiện một số lượng xác nhận để chứng minh rằng họ có thể tin tưởng vào sản phẩm.
TZHX

Nếu một cái gì đó không thành công vì một Đạo luật của Thiên Chúa (bất khả kháng) tại sao bạn có trách nhiệm sửa chữa nó theo các điều khoản bảo hành? Điều khoản pháp lý đó tồn tại để miễn cho mọi người chịu trách nhiệm đối với các sự kiện xảy ra nằm ngoài tầm kiểm soát của họ - hoặc bất kỳ ai khác.
Adam Crossland

Câu trả lời:


13

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.


3
Đây chính xác là lý do tại sao gần như tất cả các mã bạn tìm thấy tự do trên web đều có dòng chữ "CUNG CẤP NHƯ VẬY VÀ KHÔNG CÓ BẢO HÀNH".
James Love

@JamesLove: Đó là một phần vì không ai sẽ cung cấp bất kỳ loại bảo hành nào mà không được trả tiền cho nó. Nhìn vào các thỏa thuận cấp phép cho phần mềm thương mại. Trường hợp duy nhất tôi đã nghe nói về một nhà cung cấp phần mềm mở rộng và tôn trọng bảo lãnh là TurboTax.
David Thornley

6

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?

Không bao giờ

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.


3

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:".


3

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:

  • Đó là sản phẩm của tôi, trái ngược với công việc cho người khác thuê.
  • Tôi đã kiểm soát toàn bộ quá trình phát triển và phát hành phần mềm, bao gồm đặc tả, lập trình, kiểm tra và tài liệu.
  • Tôi đã chỉ định cẩn thận trong tài liệu về các trường hợp mà phần mềm có thể được chạy để bảo hành sẽ được áp dụng. Ví dụ, yêu cầu phần cứng, không chạy trong trình giả lập hệ điều hành, v.v.
  • Tôi giới hạn thời gian bảo hành.
  • Tôi thực sự tự tin về chất lượng của phần mềm

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.


Cảm ơn các ý kiến ​​và đề xuất! Vì chúng tôi chưa bao giờ có khách hàng yêu cầu điều này trước đây, điều này giúp chúng tôi rất nhiều. Lần đầu cho mọi thứ.

Vấn đề với bảo hành phần mềm là bạn đang vận chuyển các phiên bản giống hệt nhau, vì vậy nếu bạn mắc một lỗi nghiêm trọng, mọi người sẽ thu thập bảo hành. Chúng nguy hiểm.
David Thornley

Ồ, không, bạn không trả cho mọi người về bảo hành phần mềm! Nó nên giống như một bảo hành trên một chiếc xe hơi: bạn chỉ cần đảm bảo để khắc phục vấn đề. Ngoại trừ trong trường hợp phần mềm, bạn chỉ cần sửa lỗi. Tôi sẽ cập nhật câu trả lời.
Bob Murphy

2

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.


0

Từ ngữ của hợp đồng sẽ phải nêu những điều tương tự như sau:

  1. Bạn không thể mở rộng mã này
  2. Bạn không thể đảo ngược mã này
  3. Bạn không thể tích hợp mã này vào khung của mình (Tương tự như số 1, nhưng khác theo nghĩa là nó trở thành toàn bộ lớp kinh doanh của họ)
  4. Bạn không thể chuyển mã này sang các hệ điều hành khác (cửa sổ IE để unix)

Chỉ là một vài tôi có thể nghĩ ra.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.