Trong mỗi tiêu chí đánh giá sản phẩm đều đề cập tới sự cần thiết và tầm quan trọng của việc xác định và làm rõ yêu cầu trong quá trình phát triển sản phẩm. Tuy nhiên, việc quản lý Requirements và truyền đạt rõ ràng tới tất các bên của đội dự án vẫn còn mắc nhiều sai lầm. Và dưới đây là những sai lầm mà chúng tôi đã quan sát thấy trong lĩnh vực quản lý Requirements và phân tích Requirements

Thiếu sót trong giao tiếp

Cuộc đấu tranh với việc quản lý Requirements bắt đầu ngay khi dự án được start. Có nhiều lý do để cuộc chiến đó bắt đầu một cách mạnh mẽ và một trong những lý do chính để cuộc chiến đó bắt đầu là: thiếu giao tiếp và hiểu biết giữa các bên liên quan.

Một nghiên cứu của viện quản lý dự án tiết lộ: “Truyền thông không hiệu quả là nguyên nhân chính khiến dự án đi đến thất bại nhanh gấp 3 lần, và tác động tiêu cực đến sự thành công của dự án gấp hai lần.” Khi giao tiếp giữa mọi người bị cản trở sẽ mất đi sự đồng bộ với yêu cầu của dự án. Giao tiếp là nhân tố quan trọng đối với sự thành công của các sáng kiến chiến lược.

Giả sử khi có một yêu cầu từ khách hàng đối với trang web thương mại điện tử thì thách thức duy nhất của nhóm phát triển là chuyển đổi ý tưởng của khách hàng thành thứ gì đó thực sự mang lại lợi ích cho khách hàng. Hầu hết các dự án phần mềm đều làm việc theo team và có thêm một số người liên quan làm việc cùng nhau, vì vậy việc giao tiếp trong team dự án là rất quan trọng đối với thành công của một dự án phần mềm. Như bạn biết, giao tiếp tốt không chỉ là mô tả hùng hồn ý tưởng của bạn cho người khác, bạn cũng cần thu thập các phản hồi để đảm bảo bạn đã hiểu đúng, team của bạn cũng đang hiểu đúng và những bên liên quan cũng đang hiểu đúng về yêu cầu và mong muốn của KH

Vì vậy, hãy triển khai những lời thành tài liệu hóa và đó là một nơi mà tất cả các bên liên quan đều nhìn thấy yêu cầu của họ. Việc tạo tài liệu này trước khi các yêu cầu thực tế bắt đầu sẽ giúp các bên liên quan của đội dự án thấy các khái niệm ban đầu của họ được dịch thành một yêu cầu chính thức như thế nào.Nó cũng đảm bảo rằng tất cả các thông tin rõ ràng và chi tiết, mọi người liên quan đều sẽ cập nhật được thông tin chia sẻ một cách kịp thời.

Thực hiện các cuộc họp team, dự án và các bên liên quan một cách thường xuyên và định kỳ. Trong quá trình phát triển dự án thường sẽ có rất nhiều cuộc họp diễn ra. Thông thường mọi người sẽ thấy rằng chỉ có một vài các cuộc họp là quan trọng còn đa số thì thực sự không cần thiết. Và có rất nhiều các cuộc họp, ít nhất mỗi tuần một lần, của mỗi dự án, chỉ để chắc chắn rằng tất cả mọi người đang làm việc với những thông tin cập nhật mới nhất dù đã thông báo qua mail. Tại sao phải lãng phí quá nhiều thời gian như vậy? Câu trả lời rất đơn giản – Chúng ta cần phải giao tiếp để hoàn thành dự án.

Không xác định được các bên liên quan khi có sự thay đổi yêu cầu

Phần lớn các dự án của tôi trong những năm qua đã không được thực hiện.

Tất cả các thành viên trong đội dự án có thể xem tất cả các tài liệu dự án nếu họ muốn và biết nơi để tìm thấy chúng. Môi trường mở và minh bạch này được đón nhận và nó cung cấp một bối cảnh trong đó các yếu tố nằm trong sơ đồ lớn của một dự án.

Một trong những nhược điểm của tình huống này là trong giai đoạn đầu phát triển, một số nhóm lập kế hoạch chia sẻ tài nguyên hệ thống mà không thực sự thảo luận và tích hợp với các team khác trong đội dự án.

Thông thường chúng tôi thấy rằng đây là kết quả của các cuộc trò chuyện trên hành lang hoặc các cuộc họp giữa các bộ phận không được ghi lại hoặc truyền đạt đúng cách. Vấn đề phát sinh khi các yêu cầu phải thay đổi nhưng các team còn lại đang phân tích và phát triểu theo yêu cầu cũ và đã không có sự chuẩn bị để theo kịp các yêu cầu đã thay đổi vì thời hạn bàn giao sắp tới.

Một ví dụ điển hình: Trong 1 dự án phát triển phần mềm chúng ta sẽ có các team chạy song song và đòi hỏi sự tương tác liên tục bởi vì input của team nay lại là output của team khác để thực hiện công việc. Ví dự khi back-end team có một sự thay đổi nhỏ cho response trả về mà chưa thảo luận bàn bạc với các team front-end hay QA team thì sự thay đổi đó nó cũng sẽ làm mất thời gian của cả team để đi tìm lại sự thống nhất giữa các team và đảm bảo yêu cầu của dự án được đáp ứng.

Do vậy mà việc quản lý yêu cầu thay đổi và chia sẻ tới các bên liên quan trong đội dự án cũng nên thực hiện một cách rõ ràng.

Xem thiết kế là requirement

Trong một vài dự án hay công ty người ta thường xem bản thiết kế là một requirement, do đó mà nhóm dự án đều tập trung vào những gì sản phẩm sẽ trông như thế nào chứ không phải những gì sản phẩm cần làm. Mọi người thường bắt đầu chỉ định kích thước màn hình, số lượng nút, quy trình làm việc và các mục khác trước khi nhu cầu cụ thể của thiết bị được xác định.

Do vậy khi khách hàng gửi một bản thiết kế họ sẽ xem đó là một yêu cầu và tập trung vào phát triển về giao diện và lãng quên việc phân tích và làm rõ các chức năng mà khách hàng họ muốn phát triển cho sản phẩm của họ. Các thiết kế có thể và sẽ trở thành các yêu cầu nhưng ở dạng tài liệu thiết kế và không phải là một yêu cầu riêng lẻ .

Ví dụ: Một số bên liên quan trong tổ chức có thể chỉ định rằng một thiết bị sẽ có màn hình cảm ứng. Đây có thể là một ví dụ về thiết kế theo yêu cầu. Các thông số kỹ thuật hiệu suất, quy trình làm việc và các yêu cầu về môi trường đều có thể đưa ra quyết định cho các hệ thống điều khiển như thế này.

Tuy nhiên, trong trường hợp này, các quyết định thiết kế đó được loại bỏ khỏi các kỹ sư bởi yêu cầu cụ thể trong một tài liệu về thông số kĩ thuật không đủ đáp ứng yêu cầu đó. Cách tốt nhất để xử lý các mục này là chia tính năng được yêu cầu thành các yêu cầu về chức năng và thiết kế.

Từ ví dụ trên của chúng tôi, chúng tôi có thể đặt câu hỏi về lý do tại sao màn hình cảm ứng được yêu cầu từ góc độ hiệu suất và đồng thời phát triển các tài liệu khái niệm thiết kế cho các yêu cầu về thẩm mỹ và quy trình làm việc của họ.

Các thông số kỹ thuật sẽ hướng dẫn các kỹ sư về hiệu suất và đó là những gì họ cần, và tác phẩm nghệ thuật khái niệm & nghiên cứu quy trình công việc giải quyết các vấn đề hình thành hơn như cảm nhận và quy trình xử lý.

Sợ khi yêu cầu bị thay đổi

Trong lĩnh vực phát triển phần mềm, việc khách hàng thay đổi yêu cầu luôn là vấn đề khó đối với nhà phát triển. Do đó mà các đội dự án rất ngại việc yêu cầu có dự thay đổi trong quá trình chạy dự án. Phần mềm gồm một hay nhiều ứng dụng là một tập hợp các chương trình thực hiện tự động hóa một số các nhiệm vụ nghiệp vụ. Nghiệp vụ bao gồm tập hợp các chức năng như: tìm hiểu thị trường, kiểm toán, sản xuất và quản lý nhân sự... Sản phẩm phần mềm rất trừu tượng và ban đầu nó chỉ được mô tả bằng ngôn ngữ tự nhiên.

Sự thật là mọi thứ luôn thay đổi trên con đường hoàn thành một dự án. Chúng ta nên học cách nắm lấy những thay đổi và chuẩn bị cho chúng. Nhu cầu của khách hàng sẽ thay đổi, và chúng tôi học hỏi những điều như các kỹ sư và nhà thiết kế. Tất cả những điều này cung cấp cho chúng tôi nhiều thông tin và kiến thức để xây dựng một dự án tốt hơn.

Thật không may, đối với các loại vấn đề này, không có lối tắt hoặc cách khắc phục nhanh. Thiết lập và duy trì khả năng truy nguyên giữa các cấp thông số kỹ thuật khác nhau là cách duy nhất để biết yếu tố nào bị ảnh hưởng khi có gì đó thay đổi và đặc biệt là khi những thay đổi đó ảnh hưởng đến nhiều nhóm.

***Reference:***(https://www.softwaretestinghelp.com/mistakes-in-requirements-management/)