Ai nên trả tiền cho các bản sửa lỗi / lỗi? [đóng cửa]

Vì vậy, tôi mới bắt đầu tự do cả trong việc phát triển máy tính để bàn / web và khách hàng này đã chấp nhận công việc của tôi và trả tiền cho tôi cứ quay lại với tôi mỗi khi anh ta phát hiện ra lỗi, v.v. Và tôi đã thấy mình mất nhiều thời gian hơn tôi nghĩ rằng họ đã sửa chúng miễn phí. Điều này có ổn không, hay tôi nên bắt đầu tính phí hỗ trợ?

Đó là cách tốt nhất để đối phó với các bản sửa lỗi trên một công việc được cho là đã được chấp nhận và hoàn thành?

Một phần trong hợp đồng của bạn nên mô tả các thử nghiệm chấp nhận, tức là các thử nghiệm mà khách hàng sẽ thực hiện và ứng dụng của bạn cần phải vượt qua chúng để hợp đồng được thực hiện. Bất cứ điều gì không nằm trong các thử nghiệm này là trách nhiệm của khách hàng. Bất cứ điều gì được bao phủ bởi họ là của bạn.

Vì không thể (đặc biệt đối với khách hàng không có kỹ thuật) có thể thấy trước tất cả các vấn đề có thể xảy ra, bạn nên thêm vào liên hệ của mình một điều khoản chỉ định một khoảng thời gian, khi bạn sẽ khắc phục mọi vấn đề mới như một phần của hợp đồng. Sau đó, bạn chỉ nên cung cấp hỗ trợ có trả tiền.

Nó phụ thuộc.

Trong trường hợp đầu tiên, bạn nên trả tiền vì có thể lập luận rằng công việc chưa hoàn thành.

Sau đó, khách hàng sẽ được trả tiền để tiếp tục hỗ trợ.

Tuy nhiên, vấn đề là ở chỗ quyết định ranh giới ở đâu và cái gì tạo thành lỗi và tính năng mới là gì. Có yêu cầu và / hoặc kiểm tra chấp nhận đi một chặng đường dài để xác định điều này.

Bạn thực sự cần phải có những thứ này tại chỗ trước khi bạn giao việc, nhưng nếu bạn chưa có thì giờ là lúc nên nói - "Tôi sẽ hỗ trợ miễn phí trong N ngày / tuần tiếp theo, nhưng sau đó chúng tôi cần thảo luận về hợp đồng hỗ trợ "(lưu ý nhấn mạnh của tôi về" chúng tôi ").

Mặc dù đã nói tất cả, có những lúc bạn sẽ cần sửa một lỗi miễn phí và thực hiện cú đánh. Nếu không có gì khác nó xây dựng thiện chí.

Tất cả các câu trả lời ở trên là tốt. Tuy nhiên, tôi sẽ thêm một vài gạch đầu dòng để xem xét:

• Là khách hàng có giá trị với bạn? Đôi khi đáng để đi thêm vài mét để giữ cho khách hàng hài lòng nếu bạn cảm thấy họ có giá trị với bạn và sẽ mang lại cho bạn nhiều công việc hơn trong tương lai. Bạn cần tìm sự cân bằng giữa nghiêm ngặt và linh hoạt và điều này có thể khác nhau đối với mỗi khách hàng. Không có điểm nào làm mất công việc trong tương lai chỉ vì bạn kiên quyết rằng một lỗi dễ sửa chữa nằm ngoài phạm vi. Mặt khác, bạn không muốn để khách hàng đi ngang qua bạn. Đó là một sự cân bằng tinh tế!

• Là lỗi một cái gì đó có thể dễ dàng bị bỏ qua trong thử nghiệm người dùng? Chẳng hạn, lấy một lỗi liên quan đến ngày chỉ phát sinh khi một năm nhất định được nhập (nghĩ lỗi thiên niên kỷ, v.v.). Một khách hàng không thể mong đợi một cách hợp lý để phát hiện ra điều này trong quá trình thử nghiệm, do đó, trách nhiệm của bạn là khắc phục nó.

Khi tôi làm việc tự do, thỏa thuận khách hàng cơ bản của tôi đã xác định một điều kiện gọi là "chấp nhận", điều này được yêu cầu trước khi tôi đưa dự án ra công chúng. Tại thời điểm chấp nhận, đã bắt đầu một khoảng thời gian 30 ngày tôi gọi là "hỗ trợ và chạy". Sau khoảng thời gian 30 ngày đó, công việc đang diễn ra trong dự án đã được tính hóa đơn hàng giờ.

Nếu bạn có mối quan hệ tốt với khách hàng này, hãy dành tình cảm cho họ về tình hình hiện tại không khả thi đối với bạn và đề xuất mức giá hợp lý hàng giờ để bảo trì và hỗ trợ liên tục. Mọi người đôi khi nghĩ rằng mua phần mềm tùy chỉnh cũng giống như mua một chiếc bánh sandwich hoặc một cái gì đó, giống như khi nó được xây dựng xong. Nó không giống như vậy.

Nói chung, bạn có thể nhận hỗ trợ miễn phí cho số ngày cố định sau khi bạn gửi đơn. Chắc chắn một hỗ trợ miễn phí trọn đời là không thể / không thể chấp nhận được.

Đảm bảo rằng lỗi phát sinh là BUG và không thay đổi tính năng hiện có. Đối với bất kỳ thay đổi tính năng, bạn nên tính phí.

Nếu anh ta kiểm tra và ký tên, bạn có thể lập luận rằng anh ta nên trả tiền.

Nếu bạn tự hào và coi trọng công việc của mình, bạn có thể lập luận rằng bạn sẽ sửa mã. Học hỏi kinh nghiệm và xây dựng mã tốt hơn vào lần sau, hiệu quả hơn. Hoặc yếu tố lợi nhuận nhiều hơn để trang trải sửa lỗi.

Nếu chương trình thực hiện một số thứ không mong muốn hoặc bất ngờ được cung cấp cho đầu vào, thì đó là một lỗi và cần được sửa.

Bạn có thể đã trích dẫn cho phí hỗ trợ lên phía trước như là một phần bổ sung cho công việc phát triển ban đầu.

Trong hợp đồng của bạn, chỉ định tỷ lệ mỗi giờ và theo dõi thời gian của bạn. Khi bạn đưa ra giá cho khách hàng của mình, hãy xác định rằng đây là ước tính và kết quả thực tế có thể ít hơn hoặc nhiều hơn.

Luôn cập nhật cho khách hàng về tiến trình và khi anh ta chắc chắn đưa ra đề xuất, bạn có thể chỉ cần cho anh ta biết thời gian sẽ đưa bạn (nếu thay đổi nằm ngoài thông số kỹ thuật ban đầu) và anh ta có thể quyết định xem thay đổi đó có đáng tiền hay không. Do đó, chỉ những thay đổi quan trọng đối với anh ta sẽ được thêm vào.

Cá nhân tôi sẽ bao gồm các lỗi được chấp nhận so với không thể chấp nhận (hỗ trợ có trả tiền so với hỗ trợ miễn phí) trong hợp đồng, và theo cách đó bạn ít nhất có một cái gì đó bằng văn bản từ việc di chuyển. Anh ta chắc chắn sẽ tự hỏi tại sao bạn cần điều khoản đó, vì vậy hãy thẳng thắn và giải thích rằng nếu một bản cập nhật hệ điều hành mới xuất hiện mà phá vỡ một cái gì đó, đó không phải là hỗ trợ miễn phí. Tuy nhiên, các lỗi trong mã của bạn theo đặc điểm kỹ thuật ban đầu trên các nền tảng được chỉ định sẽ được đề cập.

Tuy nhiên, tôi nên đề cập rằng tôi chỉ làm công việc CNTT tự do hơn là lập trình. Điều này có thể có thể khiến khách hàng sợ hãi, nhưng chỉ cần đảm bảo rằng công việc của bạn tự bán, chuyên nghiệp hơn, hướng ngoại và hữu ích hơn so với phần còn lại và sắp tới với lý do bạn có hợp đồng nghiêm ngặt hơn.

Ngoài ra, một khách hàng không chấp nhận điều khoản đó rất có thể là một khách hàng xấu.