Cách xác định yêu cầu của phương án giải quyết

Điểm quan trọng là giữ được khả năng truy nguyên: mỗi yêu cầu cần có lý do tồn tại và lý do đó phải quay về một vấn đề, mục tiêu hoặc ràng buộc cụ thể. Nếu một yêu cầu không thể giải thích nó giúp xử lý vấn đề nào hoặc tuân thủ điều kiện nào, yêu cầu đó có nguy cơ chỉ là một giả định về cách làm.

Trước hết phải xác định đúng vấn đề mà phương án cần giải quyết

Vấn đề là điểm xuất phát của bộ yêu cầu. Khi vấn đề được mô tả quá rộng hoặc chỉ dừng ở biểu hiện bề mặt, yêu cầu của phương án cũng dễ bị lệch.

Chẳng hạn, nếu một quy trình thường xuyên giao hàng chậm, “giao hàng chậm” mới là hiện tượng quan sát được. Phần cần làm rõ là khoảng cách giữa trạng thái hiện tại và trạng thái mong muốn: đơn hàng mất quá nhiều thời gian ở công đoạn nào, hậu quả cần khắc phục là gì và kết quả nào được coi là đã giải quyết vấn đề.

Từ khoảng cách đó mới có thể hình thành yêu cầu. Nếu mục tiêu thực sự là giảm thời gian xử lý đơn hàng, yêu cầu phải thể hiện khả năng cải thiện thời gian xử lý chứ không nên mặc định ngay rằng doanh nghiệp “phải mua một phần mềm mới”. Phần mềm chỉ là một phương án có thể được xem xét; giảm thời gian xử lý mới là kết quả cần đạt.

Cách phân biệt này giúp tránh một lỗi phổ biến: biến giải pháp đang được nghĩ tới thành yêu cầu. Khi đó, quá trình lựa chọn phương án mất tính mở vì các phương án khác có thể giải quyết tốt hơn đã bị loại bỏ từ trước.

Từ vấn đề phải chuyển thành kết quả cụ thể mà phương án cần đạt

Một vấn đề chỉ cho biết điều gì đang không ổn. Để trở thành đầu vào cho việc thiết kế phương án, nó phải được chuyển thành trạng thái mong muốn hoặc tiêu chí kết quả.

Quá trình chuyển đổi thường đi theo logic:

Vấn đề hiện tại → hậu quả cần khắc phục → kết quả mong muốn → yêu cầu đối với phương án

Ví dụ, nếu vấn đề là khách hàng phải nhập cùng một thông tin nhiều lần, hậu quả có thể là tăng thời gian thao tác và tăng khả năng sai dữ liệu. Yêu cầu phù hợp vì vậy có thể là phương án phải giảm việc nhập lặp lại và bảo đảm dữ liệu được sử dụng nhất quán giữa các bước có liên quan.

Cách diễn đạt này vẫn mô tả điều phương án phải đạt nhưng chưa khóa cách thực hiện. Nhờ đó có thể so sánh nhiều lựa chọn khác nhau dựa trên cùng một kết quả mong muốn.

Yêu cầu cũng cần đủ rõ để sau này có thể kiểm tra phương án có đáp ứng hay không. Những câu như “phương án phải tốt hơn”, “dễ sử dụng” hoặc “hoạt động hiệu quả” chưa cung cấp tiêu chí đánh giá. Cần làm rõ “tốt hơn” ở khía cạnh nào, đối với ai, trong điều kiện nào và biểu hiện nào cho thấy yêu cầu đã được đáp ứng.

Ràng buộc xác định giới hạn mà mọi phương án khả thi phải tuân thủ

Nếu vấn đề xác định đích cần đạt thì ràng buộc xác định không gian mà phương án được phép hoạt động. Một phương án có thể xử lý đúng vấn đề nhưng vẫn không phù hợp nếu vi phạm các giới hạn bắt buộc.

Ràng buộc thường xuất phát từ những điều kiện đã tồn tại trước khi lựa chọn phương án, chẳng hạn ngân sách được phép sử dụng, thời hạn phải hoàn thành, hệ thống hiện có cần tương thích, nguồn nhân lực sẵn có, quy định phải tuân thủ hoặc điều kiện vận hành không thể thay đổi.

Ví dụ, doanh nghiệp cần cải thiện tốc độ xử lý nhưng hệ thống mới bắt buộc phải tích hợp với hạ tầng hiện tại. Khi đó, khả năng tương thích không đơn thuần là một ưu điểm để cộng điểm; nó là điều kiện để phương án có thể được triển khai.

Tuy nhiên, không nên gọi mọi mong muốn là ràng buộc. Một điều kiện chỉ nên được xem là ràng buộc khi thực sự giới hạn phạm vi lựa chọn hoặc không thể tùy ý bỏ qua. Nếu một tiêu chí chỉ làm phương án hấp dẫn hơn nhưng vẫn có thể đánh đổi, nó phù hợp hơn với nhóm yêu cầu ưu tiên hoặc tiêu chí đánh giá.

Cần tách yêu cầu bắt buộc khỏi mong muốn và giả định về giải pháp

Không phải tất cả yêu cầu đều có cùng mức độ quan trọng. Việc trộn lẫn yêu cầu bắt buộc, mong muốn và một phương án đã được hình dung trước dễ làm bộ yêu cầu trở nên cứng nhắc.

Yêu cầu bắt buộc là những điều phương án phải đáp ứng để thực sự giải quyết vấn đề hoặc tuân thủ ràng buộc. Nếu thiếu chúng, phương án không còn đạt mục tiêu cơ bản.

Mong muốn là những đặc điểm tạo thêm giá trị nhưng có thể được cân nhắc cùng với chi phí, thời gian hoặc các lợi ích khác. Chúng hữu ích khi so sánh những phương án đều đã đạt các yêu cầu bắt buộc.

Trong khi đó, giả định về giải pháp thường xuất hiện dưới dạng một công nghệ, công cụ hoặc cách tổ chức cụ thể. Ví dụ, “phải sử dụng ứng dụng di động” là một yêu cầu về cách thực hiện. Chỉ khi bản thân việc sử dụng ứng dụng di động xuất phát từ một ràng buộc thực sự thì nó mới trở thành yêu cầu bắt buộc. Nếu mục tiêu chỉ là người dùng có thể thao tác từ xa, nên diễn đạt yêu cầu theo khả năng cần có thay vì khóa trước công nghệ.

Phân tách ba nhóm này giúp giữ được mối liên hệ giữa yêu cầu với bản chất vấn đề, đồng thời tạo không gian để tìm phương án hiệu quả hơn.

Mỗi yêu cầu phải được kiểm tra về tính cần thiết, rõ ràng và khả thi

Sau khi hình thành bộ yêu cầu, cần kiểm tra ngược từng yêu cầu thay vì mặc nhiên chấp nhận tất cả. Một yêu cầu có giá trị khi có thể trả lời được ba câu hỏi: tại sao cần yêu cầu này, yêu cầu này có nghĩa đủ rõ để các bên hiểu giống nhau hay không, và có khả năng đáp ứng nó trong các ràng buộc hiện có hay không.

Tính cần thiết được xác nhận bằng khả năng truy nguyên về vấn đề, mục tiêu hoặc ràng buộc. Nếu bỏ một yêu cầu mà việc giải quyết vấn đề không thay đổi và không có điều kiện bắt buộc nào bị vi phạm, cần xem lại lý do giữ yêu cầu đó.

Tính rõ ràng liên quan đến khả năng đánh giá. Hai người sử dụng cùng một yêu cầu nên có cơ sở tương đối thống nhất để xác định một phương án có đáp ứng hay không. Vì vậy, những khái niệm mơ hồ cần được chuyển thành đặc tính, điều kiện hoặc kết quả quan sát được.

Tính khả thi lại buộc các yêu cầu phải được xem trong quan hệ với nhau. Chẳng hạn, yêu cầu hoàn thành rất nhanh, chi phí rất thấp và đồng thời đạt mức chức năng rất rộng có thể tạo xung đột. Khi đó không nên âm thầm bỏ một yêu cầu mà cần nhận diện xung đột, xác định đâu là điều kiện bắt buộc và đâu là phần có thể đánh đổi.

Bộ yêu cầu phải đủ để đánh giá phương án nhưng không biến thành bản mô tả sẵn một giải pháp

Giá trị thực tế của bộ yêu cầu thể hiện rõ nhất ở giai đoạn đánh giá các phương án. Một bộ yêu cầu tốt tạo ra cùng một “thước đo” cho các lựa chọn khác nhau.

Trước tiên, có thể loại những phương án không đáp ứng yêu cầu bắt buộc hoặc vi phạm ràng buộc. Với các phương án còn lại, những yêu cầu có thể đánh đổi được dùng để xem xét mức độ đáp ứng, lợi ích và những giới hạn đi kèm.

Ví dụ, nếu vấn đề là thời gian xử lý kéo dài, các phương án có thể gồm điều chỉnh quy trình, tự động hóa một số công đoạn hoặc thay đổi cách phân bổ công việc. Nếu yêu cầu được viết là “phải mua hệ thống tự động hóa”, chỉ một hướng giải quyết được giữ lại. Ngược lại, nếu yêu cầu là “phải loại bỏ các bước xử lý lặp gây chậm tiến độ trong phạm vi nguồn lực cho phép”, nhiều phương án vẫn có cơ hội được đánh giá trên cùng mục tiêu.

Vì vậy, mức chi tiết của yêu cầu cần dừng ở điểm đủ để xác định kết quả, điều kiện và giới hạn phải đáp ứng. Các quyết định về cấu trúc hoặc công nghệ chỉ nên được khóa lại khi chính chúng là ràng buộc đã được xác lập.

Yêu cầu của phương án giải quyết được xác định bằng cách đi từ vấn đề thực tế đến kết quả cần đạt, sau đó đặt kết quả đó trong các ràng buộc phải tuân thủ. Mỗi yêu cầu cần truy nguyên được về một vấn đề, mục tiêu hoặc giới hạn cụ thể; đồng thời phải đủ rõ để dùng làm căn cứ đánh giá. Cách tiếp cận này giúp bộ yêu cầu định hướng đúng việc tìm phương án mà không vô tình biến một giải pháp được nghĩ tới trước thành lựa chọn duy nhất.