Một người phát triển phần mềm viết cho tôi: “Chúng tôi có vài dự án thất bại. Khách hàng giận nhưng người quản lí dự án bảo chúng tôi rằng đấy là lỗi của khách hàng vì họ cứ thay đổi yêu cầu. Chúng tôi bắt đầu dự án mới nhưng tôi sợ rằng chúng tôi sẽ phạm cùng sai lầm lẫn nữa. Chúng tôi có thể làm gì để tránh vấn đề này? Xin thầy lời khuyên.”

Đáp: Nếu khách hàng cứ thay đổi yêu cầu thì bạn cần có một kĩ sư yêu cầu hay người phân tích doanh nghiệp dành thời gian cùng khách hàng để thu được yêu cầu tốt hơn. Đây là vai trò quan trọng trong phát triển phần mềm nhưng nhiều công ti không chú ý. Nếu yêu cầu là sai thì mọi thứ sẽ sai chẳng thành vấn đề bạn thiết kế hay viết mã tốt tới đâu. Nếu công ti của bạn không có ai đó làm điều này thì họ nên thuê người có thể làm việc đó. Khi dự án thất bại, người quản lí của bạn lẽ ra phải không nên trách khách hàng mà nên nhận diện nguyên nhân và sửa nó để cho nó sẽ không xảy ra nữa. Khi khách hàng không hài lòng thì đó là kinh doanh kém. Không công ti nào có thể tồn tại nếu khách hàng của họ không hài lòng. Khi dự án bị trễ, nó cần nhiều thời gian hơn, nhiều tiền hơn, và nhiều nỗ lực hơn đã lập kế hoạch trước đây. Điều đó nghĩa là công ti phải trả tiền cho việc làm thêm và điều đó nghĩa là mất nhiều tiền hơn.

Thay đổi yêu cầu là vấn đề thông thường trong công nghiệp phần mềm. Nó thường là do thiếu tri thức về yêu cầu phần mềm. Nhiều người quản lí dự án nghĩ rằng họ hiểu điều khách hàng cần và tiến hành phát triển mà không có việc kiểm nghiệm nào của khách hàng. Nhiều người phát triển đoán chừng họ biết mọi tính năng mà khách hàng cần rồi bắt đầu thiết kế và viết mã mà không có kiểm điểm nào của khách hàng. Tiến bộ được đo bằng từng dòng mã được xây dựng qua qui trình cho tới khi yêu cầu bắt đầu thay đổi. Sửa phần mềm sau khi dựng là tốn chi phí và thời gian. Nó thường gây ra lãng phí nỗ lực khổng lồ với hàng trăm giờ không năng suất và hàng trăm dòng mã thay đổi. Đây là lí do tại sao bạn cần ai đó người hiểu yêu cầu và làm việc chặt chẽ với khách hàng để có được yêu cầu đúng sao cho bạn không phạm sai lầm lần nữa.

Có những cách nhìn khác nhau về yêu cầu. Cách nhìn của người quản lí về yêu cầu thường là quan niệm mức cao về sản phẩm hay vấn đề doanh nghiệp mà phải được giải quyết. Cách nhìn của người dùng về yêu cầu chủ yếu là chức năng, giao diện và dẫn hướng các màn hình. Nếu yêu cầu chủ yếu là chức năng, tổ dự án có thể không hiểu các thông tin đa dạng ẩn dưới cái nhìn về chức năng. Kết quả là mong đợi của khách hàng có thể không được đạt tới.

Để tránh vấn đề này, tổ dự án phải hiểu vài cách nhìn về yêu cầu. Cách nhìn mức cao nhất là yêu cầu doanh nghiệp, biểu thị cho các mục tiêu của khách hàng. Đây thực sự là viễn kiến và phạm vi của dự án của bạn. Cách nhìn mức thứ hai là yêu cầu của người dùng, điều mô tả cho mọi nhiệm vụ mà người dùng phải làm khi dùng phần mềm. Những điều này được nắm bắt tốt nhất dưới dạng các trường hợp sử dụng, điều là kịch bản cho các tương tác điển hình giữa người dùng và hệ thống. Đây là kiến trúc của hệ thống với phần cứng, giao diện phần mềm và dẫn hướng các màn hình. Tuy nhiên, một mình các trường hợp sử dụng không cung cấp đủ chi tiết cho người phát triển biết phải xây dựng cái gì. Do đó, bạn cần cách nhìn mức thứ ba hay cách nhìn chức năng điều suy dẫn ra từ trường hợp sử dụng. Yêu cầu chức năng xác định rõ ràng các điều đặc biệt phần mềm phải làm. Đây là thiết kế về hệ thống với từng chức năng được nhận diện rõ ràng. Tuy nhiên, có cách nhìn khác có tên là cách nhìn phi chức năng hay đặc tính chất lượng điều không tới từ khách hàng mà tới từ người phát triển, điều giải quyết với chất lượng của phần mềm như hiệu năng, tính hiệu quả, tính dùng được, hay tính đổi qui mô được v.v.

Bằng việc hiểu các cách nhìn khác nhau, người phát triển có thể tổ chức công việc của họ một cách hệ thống để đáp ứng cho mong đợi của khách hàng và phát triển sản phẩm phần mềm tốt hơn.

—-English version—-

Systemic software development

A software developer wrote to me: “We had several project failures. Customers were angry but the project manager told us that they were customer’s faults because they kept changing requirements. We are starting a new project but I am afraid that we will make the same mistake again. What can we do to avoid this problem? Please advice.”

Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.

Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.

There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.

To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.

By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.