- Thu thập yêu cầu là quá trình xác định, thu thập và phân tích các yêu cầu của các bên liên quan (stakeholders) để hiểu rõ mục tiêu, nhu cầu và mong muốn của dự án.
- Là giai đoạn nền tảng, giúp xác định phạm vi, mục tiêu và các yếu tố quan trọng khác để đảm bảo dự án thành công.
Mục tiêu chính của Requirements Gathering
Là tạo ra một tài liệu yêu cầu chi tiết và rõ ràng, thường được gọi là Đặc tả Yêu cầu (Requirements Specification). Tài liệu này sẽ đóng vai trò quan trọng cho toàn bộ đội ngũ phát triển, giúp họ hiểu được:
- Mục tiêu của dự án: Dự án được tạo ra để giải quyết vấn đề gì?, xác định ai là người dùng/khách hàng và họ cần gì.
- Chức năng cần có: Sản phẩm hoặc hệ thống cần làm được những gì?
- Giới hạn và điều kiện: Các yêu cầu phi chức năng (non-functional requirements) như hiệu suất, bảo mật, và khả năng sử dụng.
- Đảm bảo tất cả các bên liên quan có cùng nhận thức về phạm vi và mục tiêu.
Phương pháp thu thập yêu cầu phổ biến
- Phỏng vấn. Đây là một trong những phương pháp hiệu quả nhất nhưng cũng tốn kém nhất. Thực hiện phỏng vấn cho phép bạn quan sát người mình đang nói chuyện, đánh giá mức độ hiểu biết của họ và nắm bắt các tín hiệu phi ngôn ngữ. Tuy nhiên, phương pháp này đòi hỏi kỹ năng giao tiếp tốt và có thể tốn thời gian cũng như chi phí.
- Khảo sát. Khảo sát là một cách hiệu quả về mặt chi phí để thu thập thông tin từ lượng lớn đối tượng. Chúng dễ dàng phân phối và không đòi hỏi nhiều thời gian của người trả lời. Tuy nhiên, khảo sát cũng có những hạn chế. Chúng thường gặp khó khăn với các câu hỏi mở và thiếu tính cá nhân như một cuộc phỏng vấn.
- Động não. Một buổi động não có thể là một công cụ mạnh mẽ để tạo ra ý tưởng. Tuy nhiên, nó có thể gây khó khăn cho những người tham gia hướng nội, những người có thể cảm thấy không thoải mái khi chia sẻ ý tưởng trong môi trường nhóm. Để giảm thiểu điều này, hãy cân nhắc sử dụng các buổi hội thảo có người hướng dẫn để hướng dẫn quá trình và đảm bảo tiếng nói của mọi người đều được lắng nghe.
- So sánh chuẩn. Điều này bao gồm việc so sánh dự án của bạn với các tiêu chuẩn ngành hoặc đối thủ cạnh tranh để xác định các lĩnh vực cần cải thiện hoặc đổi mới. So sánh chuẩn có thể cung cấp những hiểu biết giá trị về những gì đang hiệu quả trên thị trường.
- Tạo mẫu. Việc tạo mẫu cho phép các bên liên quan tương tác với phiên bản sơ bộ của sản phẩm. Phương pháp thực hành này có thể giúp làm rõ các yêu cầu và xác định các vấn đề tiềm ẩn ngay từ đầu quá trình phát triển.
- Quan sát. Việc quan sát người dùng trong môi trường tự nhiên của họ có thể cung cấp những hiểu biết sâu sắc về cách họ tương tác với các hệ thống hoặc quy trình hiện tại. Kỹ thuật này đặc biệt hữu ích để xác định những nhu cầu hoặc vấn đề chưa được nói ra mà người dùng có thể chưa nói rõ.
- Phân tích tài liệu. Phân tích tài liệu hiện có, chẳng hạn như kế hoạch dự án trước đây, hướng dẫn sử dụng hoặc hướng dẫn quy định, có thể khám phá các yêu cầu thiết yếu và tránh bỏ sót các khía cạnh quan trọng của dự án.
Tầm quan trọng của Requirements Gathering
Nếu quá trình Thu thập Yêu cầu được không thực hiện không, dự án sẽ gặp phải nhiều rủi ro:
- Sản phẩm không đáp ứng nhu cầu: Dẫn đến việc phải làm lại (rework), tốn kém thời gian và chi phí.
- Thay đổi liên tục: Yêu cầu thay đổi thường xuyên trong quá trình phát triển, làm gián đoạn tiến độ.
- Mâu thuẫn giữa các bên: Thiếu sự thống nhất giữa các bên liên quan do yêu cầu không rõ ràng.
Những sai lầm phổ biến thường gặp ở giai đoạn này
- Không xác định đầy đủ các bên liên quan (Stakeholders)
Sai lầm lớn nhất là chỉ làm việc với một vài người quản lý cấp cao mà bỏ qua những người trực tiếp sử dụng sản phẩm hoặc các bộ phận liên quan. Điều này dẫn đến việc bỏ sót những yêu cầu quan trọng và tạo ra một sản phẩm không thực sự hữu ích trong thực tế.
Hậu quả: Các yêu cầu không đầy đủ, không chính xác, dẫn đến việc sản phẩm cuối cùng không đáp ứng được nhu cầu thực tế của người dùng cuối.
- Yêu cầu không rõ ràng và mơ hồ
Đây là vấn đề muôn thuở. Thay vì yêu cầu cụ thể, BA thường nhận được những câu nói chung chung như “Hệ thống cần phải dễ sử dụng” hay “Phần mềm cần hoạt động nhanh”. Những yêu cầu mơ hồ này khiến đội ngũ phát triển khó hiểu và dễ dẫn đến sự sai lệch so với mong đợi ban đầu.
Hậu quả: Đội ngũ kỹ thuật phải đoán ý, sản phẩm được phát triển không đúng với mong muốn, gây lãng phí thời gian và chi phí để chỉnh sửa.
- Không ưu tiên các yêu cầu
Việc thu thập được hàng trăm yêu cầu mà không sắp xếp theo mức độ ưu tiên sẽ khiến đội ngũ phát triển không biết nên làm gì trước. Mọi thứ đều được coi là quan trọng, dẫn đến tình trạng làm việc không hiệu quả và dễ bị quá tải.
Hậu quả: Dự án có thể không hoàn thành các tính năng cốt lõi đúng hạn, hoặc tệ hơn là tốn thời gian vào những tính năng không mang lại nhiều giá trị.
- Thiếu tài liệu hóa hoặc tài liệu không đầy đủ
Cho dù có một buổi thảo luận hiệu quả, nếu không được tài liệu hóa một cách chi tiết và có hệ thống, các yêu cầu sẽ dễ dàng bị quên hoặc hiểu sai. Tài liệu không đầy đủ làm cho quá trình bàn giao công việc và kiểm thử trở nên khó khăn.
Hậu quả: Gây ra sự hiểu lầm giữa các bộ phận, các thành viên mới tham gia dự án khó nắm bắt thông tin và quá trình kiểm thử không có cơ sở rõ ràng để đối chiếu.
- Giả định thay vì đặt câu hỏi
Một BA giỏi không bao giờ giả định. Sai lầm phổ biến là dựa vào kinh nghiệm hoặc các dự án tương tự để tự phỏng đoán nhu cầu của khách hàng, thay vì đặt câu hỏi, lắng nghe và xác nhận.
Hậu quả: Sản phẩm có thể đáp ứng được các yêu cầu mà BA giả định nhưng lại bỏ qua các nhu cầu thực tế và độc đáo của khách hàng.
- Bỏ qua các yêu cầu phi chức năng (Non-functional requirements)
Yêu cầu phi chức năng, như hiệu suất, bảo mật, khả năng mở rộng, thường bị xem nhẹ trong giai đoạn đầu. Tuy nhiên, chúng lại quyết định đến chất lượng và khả năng tồn tại lâu dài của sản phẩm.
Hậu quả: Hệ thống có thể hoạt động đúng chức năng nhưng lại chậm, dễ bị tấn công hoặc khó nâng cấp khi cần thiết.
Bài viết khác
Gitbook
Là một nền tảng chuyên biệt được thiết kế để tạo và quản lý tài liệu một cách hiệu quả, đặc biệt phù hợp với các đội ngũ phát triển phần mềm và dự án công nghệ. Nó kết hợp sức mạnh của hệ thống quản lý phiên bản Git với một giao diện […]
SharePoint
Là nền tảng Microsoft SharePoint, giúp cho doanh nghiệp có thể cộng tác làm việc trên nền tảng web. Được Microsoft cho ra đời lần với mục đích chủ yếu là để lưu trữ và quản lý mọi tài liệu của doanh nghiệp, nhưng SharePoint ngày càng được phát triển để sử dụng một […]
Confluence
Là việc sử dụng nền tảng Confluence (của Atlassian) để tạo, lưu trữ, tổ chức và chia sẻ tài liệu dự án theo dạng wiki nội bộ, được dùng như một hub tài liệu tập trung để tất cả thành viên và stakeholders có thể truy cập, cập nhật và cộng tác trong suốt vòng […]
Notion
Là một ứng dụng quản lý công việc đa năng, hỗ trợ người dùng trong việc ghi chú, theo dõi nhiệm vụ, quản lý dự án, xây dựng wiki và lưu trữ cơ sở dữ liệu trong cùng một nền tảng. Là một ứng dụng viết ghi chú, nhưng nếu biết cách sử dụng, người […]
Stakeholder Management
Hay còn gọi là Quản lý các bên liên quan, là một quá trình chiến lược và có hệ thống nhằm xác định, phân tích, lập kế hoạch và thực hiện các hành động để tương tác hiệu quả với các cá nhân, nhóm, hoặc tổ chức có ảnh hưởng hoặc bị ảnh hưởng bởi […]
Wireframing & Prototyping
Wireframing Là quá trình tạo ra bản phác thảo khung xương (blueprint) của giao diện người dùng (UI) để mô tả bố cục, vị trí các thành phần, và cách luồng thông tin được trình bày trên màn hình trước khi sản phẩm thực tế được phát triển. Là một trong những công cụ […]
Khoá học lập trình game con rắn cho trẻ em 
