Một sinh viên hỏi tôi: Làm sao thầy biết liệu dự án phần mềm là thành công hay không? Nếu phần mềm chạy tốt, nó có là thành công không? Nếu mã qua được mọi kiểm thử nó có là thành công không?”

Đáp: Dự án phần mềm thành công nếu nó được chuyển giao cho khách hàng đúng thời gian, trong chi phí, có mọi chức năng được khách hàng yêu cầu, có lỗi thấp, và nó cung cấp giá trị cho khách hàng. Thời gian và chi phí có liên quan với nhau. Thời gian tổ dành cho dự án cũng là phần lớn của chi phí. Phần khác là chi phí lao động và nếu dự án cần nhiều người hơn nó đã được lập kế hoạch điều đó sẽ tốn chi phí nhiều hơn. Nếu dự án chậm (cần nhiều thời gian hơn) nó sẽ tốn phí nhiều hơn. Tất nhiên hoặc khách hàng sẽ phải trả nhiều hơn hoặc công ti sẽ phải chi thêm tiền phụ thêm.

Phần mềm phải có mọi chức năng mà khách hàng yêu cầu trong đặc tả yêu cầu phần mềm (SRS) và hơn nữa bởi vì có nhiều “chức năng suy dẫn” mà tổ sẽ thêm vào cho các chức năng được yêu cầu để làm cho sản phẩm cuối cùng làm việc tốt hơn. Tất nhiên, có thể tốn phí nhiều hơn khi tổ phải chi thêm thời gian phụ cho chúng. Không phần mềm nào “không lỗi” nhưng có khác biệt rõ ràng giữa phần mềm làm việc được, với ít lỗi có thể được sửa và phần mềm có nhiều lỗi phải mất nhiều thời gian và nỗ lực hơn và có thể vô dụng. Ngay cả phần mềm được chuyển giao “đúng thời gian, trong chi phí” thực tế không được kết thúc khi nó được chuyển giao cho khách hàng và chính khách hàng sẽ phải tìm ra chức năng bị thiếu và gửi nó trả lại để sửa.

Vấn đề mấu chốt là: Khách hàng có dùng nó không? Nó tạo ra bao nhiêu giá trị trong kinh doanh của khách hàng? Nó giúp cho khách hàng giải quyết vấn đề được bao nhiêu? Nhiều người phần mềm KHÔNG quan tâm về vấn đề giá trị bởi vì điều này không được làm tài liệu trong SRS cho nên nó “không phải là vấn đề của chúng ta”. Tổ phần mềm tạo ra nó, và nó làm việc, cho nên nếu họ không dùng nó, thế thì đó là vấn đề của họ, không phải của chúng ta. Đây KHÔNG phải là cách tốt để đạt tới sự hài lòng của khách hàng bởi vì tổ phần mềm cần hiểu tại sao phần mềm không được dùng? Có thể nó quá khó dùng không được? Vậy đó là vấn đề về tính dùng được. Có lẽ cách khách hàng làm tài liệu yêu cầu là KHÔNG tốt cho nên phần mềm không thể giải quyết được vấn đề. Vậy thì đó là vấn đề khêu gợi yêu cầu làm kém. Dù bất kì lí do nào, nếu phần mềm KHÔNG được dùng, nó không có giá trị và nếu bạn là người phát triển phần mềm chuyên nghiệp, bạn sẽ thấy lí do và đề nghị giải pháp để chắc chắn rằng khách hàng sẽ thoả mãn toàn bộ. Nếu khách hàng hài lòng, thử đoán xem họ sẽ trao dự án tiếp cho ai?

—-English version—-

Sucessful software project

A student asked me: How do you know if a software project is successful or not? If the software run well, is it successful? If the code passes all tests is it successful?”

Answer: A software project is successful if it is delivered to customers on time, within cost, has all functions required by the customer, has low defects, and it provides value to customer. Time and cost are related to each other. The time the team spends on the project is also big part of the cost. The other is the labor cost and if the project needs more people than it was planned for than it will cost much more. If the project is late (Need more time) than it will cost more. Of course either the customer will have to pay more for it or the company will have to come up with additional money.

The software must have all functions that the customer asks for in the software requirements specification (SRS) and more because there are many “derived functions” that the team comes up with in addition to the required functions to make the final product works better. Of course, it may cost more as the team has to spend extra time for them. No software has “zero defect” but there is a clear difference between software that works, with few defects that can be fixed and software that has so many defects that take much more time and efforts and maybe unusable. Even software that is delivered “on time, within cost” is not actually finished when it is delivered to customer and it is the customer will have to find the missing functions and send it back to be fixed.

The critical issue is: Are customer using it? How much value is it producing in customer’s business? How much it help the customer solve the problems? Many software people do NOT care about the value issue because this is not documented in the SRS so it is “not our problem”. Software team creates it, and it works, so if they do not use it, then that is their problem, not ours. This is NOT a good way to achieve customer’s satisfaction because software team need to understand why the software is not being used? Maybe it is too difficult to use? Then it is a usability issue. Perhaps the way customer document the requirements is NOT good so the software cannot solve the problem. Then it is a Poor requirements elicitation issue. Whatever the reason, if the software is NOT being used, it has no value and if you are a professional software developer, you will find out the reason and propose a solution to make sure that the customer will be totally satisfies. If the customer is happy, guess who do they will give the next project to?