Đó không phải là về phương pháp, mà là về giao tiếp với khách hàng.
Tôi đã có nhiều tình huống trong đó khách hàng muốn liên tục thêm các tính năng mới vào một dự án chưa hoàn thành và đã ngạc nhiên tại sao nó sẽ làm tăng chi phí chung và sự chậm trễ. Bối cảnh và tính cách của những khách hàng đó là khác nhau, nó đòi hỏi những cách tiếp cận khác nhau, nhưng tôi có thể cố gắng tách ra một số hướng dẫn và lời khuyên:
- Đảm bảo rằng khách hàng có quyền truy cập vào thông tin chung cần thiết để hiểu lý do tại sao thay đổi trong yêu cầu có thể ảnh hưởng đến cả chi phí và sự chậm trễ . Nói cách khác, xuất bản một số bài viết về những điều đó, giải thích những gì một người phi kỹ thuật có thể không biết gì cả.
Ví dụ, đối với hầu hết mọi người, thật kỳ lạ khi một thay đổi mà họ cho là nhỏ bé có thể có tác động rất lớn đến dự án và rất tốn kém (xem ví dụ trong câu hỏi của tôi ). Nếu họ yêu cầu thực hiện một số thay đổi và mỗi khi bạn nói với họ, mà không giải thích bất cứ điều gì, họ sẽ phải trả hàng ngàn đô la khi họ mong đợi nó miễn phí hoặc vài chục đô la, họ có thể sẽ nghĩ bạn chỉ là ăn cắp tiền của họ. Điều này đặc biệt đúng vì một số lập trình viên và công ty phần mềm phi đạo đức phát triển các sản phẩm không thể nhận ra (vì vậy bạn không thể yêu cầu thay đổi nó sau bởi một nhà phát triển bình thường), sau đó yêu cầu bạn trả quá nhiều cho mỗi sửa đổi.
- Đảm bảo rằng khách hàng đã hiểu lý do tại sao thay đổi cụ thể mà cô ấy muốn có tác động đến chi phí . Vì vậy, bạn có thể cung cấp cho cô ấy các liên kết đến bài viết của bạn (xem điểm trước) hoặc chỉ tóm tắt, theo cách phi kỹ thuật, những gì được yêu cầu để thực hiện thay đổi được yêu cầu.
Giải thích như vậy cũng là một ý tưởng tốt vì chúng cho phép khách hàng của bạn hiểu rõ hơn về sản phẩm và sự thay đổi. Trong một vài trường hợp, một số khách hàng của tôi đã kết thúc bằng cách nói rằng sự thay đổi họ muốn không quá thông minh và họ sẽ thực hiện theo cách khác. Bạn cũng có thể đề xuất những điều. Nó được một số khách hàng đánh giá cao (cảnh báo: một số người khác ghét nó) và cho thấy rằng bạn biết bạn đang nói về điều gì (bằng cách so sánh với con khỉ mã chỉ dịch các yêu cầu thành mã, mà không suy nghĩ quá nhiều về các cách tiếp cận có thể) .
- Đảm bảo rằng khách hàng không thể làm bất cứ điều gì cô ấy muốn, trừ khi cô ấy thực sự chắc chắn. Đối với một số người, cách duy nhất là khóa các yêu cầu dứt khoát trước khi bắt đầu viết mã . Nếu không, đó là một thảm họa, và dự án sẽ không bao giờ kết thúc . Đối với những người khác, đó là một ý tưởng tốt để không bao giờ thấy một dự án bị hủy bỏ (nói chung, khách hàng của tôi có quyền truy cập trực tiếp vào sản phẩm bị phá hủy từ rất sớm, vì vậy họ cũng có thể đưa ra nhận xét / điều chỉnh sớm).
Ví dụ: tôi có một khách hàng, sau khi gửi yêu cầu "cuối cùng", trung bình, mười thư mỗi ngày với mười thay đổi yêu cầu, từ các sửa đổi nhỏ ("Bạn có thể thay đổi độ rộng đường viền của vùng giữa trên trang chủ từ ba đến sáu pixel? ") đến những thay đổi ảnh hưởng đến toàn bộ dự án (sau hai tháng phát triển, một tuần trước khi phát hành:" Cuối cùng, tôi nghĩ ASP.NET là một ý tưởng tồi. Bạn có thể chuyển sang PHP không? " ).
Vì vậy, đối với khách hàng đó , chúng tôi buộc phải khóa tất cả các yêu cầu trước khi viết mã. Nó đã được viết trong hợp đồng. Không có thay đổi được chấp nhận trước khi phát hành cuối cùng.
Cuối cùng, điều đó không tệ lắm, vì tò mò, chúng tôi đã cho phép tổ chức rất nhiều: dự án đã được phát hành, theo yêu cầu cũ, và sau đó, vài ngày sau, chúng tôi bắt đầu phiên bản tiếp theo từ đầu với một bộ hoàn toàn khác của các yêu cầu.