Phát triển phần mềm hệ thống
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.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
