Cách xác định yêu cầu giải quyết vấn đề

Một yêu cầu có giá trị phải trả lời được ít nhất một câu hỏi thực tế: giải pháp cần tạo ra kết quả gì, phải đáp ứng điều kiện nào hoặc không được vượt qua giới hạn nào. Vì vậy, câu như “cần cải thiện quy trình” mới phản ánh mong muốn; còn “giảm thời gian xử lý nhưng vẫn duy trì các bước kiểm soát bắt buộc” đã tiến gần hơn đến một yêu cầu có thể dùng để giải quyết vấn đề.

Xác định mục tiêu mà việc giải quyết vấn đề phải đạt được

Mục tiêu là điểm xuất phát vì nó xác định trạng thái mong muốn sau khi vấn đề được xử lý. Nếu mục tiêu chưa rõ, rất khó phân biệt đâu là yêu cầu thực sự và đâu chỉ là một ý tưởng về cách làm.

Một mục tiêu cần làm rõ ba thành phần: hiện trạng đang gây vấn đề gì, trạng thái mong muốn khác hiện trạng ở điểm nào và kết quả nào chứng minh rằng sự thay đổi đó đã xảy ra.

Ví dụ, “dịch vụ khách hàng chưa tốt” chưa đủ để hình thành yêu cầu. Cần xác định vấn đề cụ thể hơn, chẳng hạn khách hàng phải chờ quá lâu trước khi nhận phản hồi. Trạng thái mong muốn khi đó là thời gian phản hồi được rút ngắn đến mức phù hợp. Từ mục tiêu này mới có thể hình thành những yêu cầu như khả năng tiếp nhận yêu cầu nhanh, phân loại đúng trường hợp và chuyển thông tin đến người có trách nhiệm mà không tạo thêm bước xử lý không cần thiết.

Điểm quan trọng là mục tiêu mô tả kết quả cần đạt, không mặc định phương tiện để đạt kết quả đó. Nếu ngay từ đầu quy định “phải xây một ứng dụng mới” trong khi mục tiêu thực tế chỉ là giảm thời gian xử lý, phạm vi giải pháp đã bị thu hẹp trước khi nguyên nhân và các phương án được đánh giá.

Chuyển mục tiêu thành kết quả có thể kiểm tra

Mục tiêu càng chung thì yêu cầu càng dễ mơ hồ. Vì vậy, cần chuyển mục tiêu thành các kết quả có thể nhận biết hoặc kiểm tra được.

Thay vì chỉ yêu cầu “tăng hiệu quả”, cần xác định hiệu quả biểu hiện ở đâu: giảm thời gian, giảm lỗi, giảm chi phí, tăng khả năng xử lý, tăng độ chính xác hay giảm số bước không tạo giá trị. Không phải vấn đề nào cũng cần một con số ngay từ đầu, nhưng kết quả phải đủ rõ để sau này có thể xác định phương án đã giải quyết đúng vấn đề hay chưa.

Đây cũng là ranh giới giữa mong muốn và yêu cầu. Mong muốn cho biết điều gì được kỳ vọng; yêu cầu xác định điều kiện cụ thể mà kết quả giải quyết vấn đề phải thỏa mãn.

Xác định khoảng cách giữa hiện trạng và trạng thái mong muốn

Yêu cầu không chỉ được suy ra từ mục tiêu cuối cùng mà còn từ khoảng cách cần được khắc phục. Hai tình huống có cùng mục tiêu nhưng khác nguyên nhân hoặc khác hiện trạng có thể cần những yêu cầu hoàn toàn khác nhau.

Có thể biểu diễn logic này như sau:

Hiện trạng → Khoảng cách cần khắc phục → Thay đổi cần tạo ra → Yêu cầu

Giả sử mục tiêu là giảm thời gian hoàn thành một công việc. Nếu nguyên nhân nằm ở việc phải nhập cùng dữ liệu nhiều lần, yêu cầu cần tập trung vào việc giảm thao tác lặp lại hoặc tái sử dụng dữ liệu. Nếu nguyên nhân nằm ở thời gian chờ phê duyệt, yêu cầu phải tập trung vào luồng phê duyệt. Cùng một mục tiêu “nhanh hơn” nhưng yêu cầu khác nhau vì cơ chế tạo ra vấn đề khác nhau.

Do đó, trước khi xác lập yêu cầu cần kiểm tra mỗi yêu cầu có quan hệ trực tiếp với một khoảng cách thực tế hay không. Nếu một yêu cầu không xử lý nguyên nhân, không tạo ra thay đổi cần thiết và cũng không phục vụ mục tiêu, nó có nguy cơ chỉ làm tăng phạm vi mà không tăng giá trị giải quyết vấn đề.

Xác định các ràng buộc mà giải pháp phải tuân thủ

Mục tiêu cho biết cần đạt đến đâu, còn ràng buộc xác định không gian mà giải pháp được phép vận hành. Một phương án có thể đạt mục tiêu nhưng vẫn không khả thi nếu vi phạm những giới hạn quan trọng.

Các ràng buộc cần được xác định theo bản chất của vấn đề, thay vì áp dụng một danh sách cố định. Những nhóm thường cần xem xét gồm:

·         Phạm vi: Đối tượng, quy trình hoặc khu vực nào được phép thay đổi

·         Thời gian: Khi nào kết quả phải đạt được hoặc thời gian xử lý tối đa có thể chấp nhận

·         Nguồn lực: Nhân lực, ngân sách, thiết bị, dữ liệu hoặc năng lực sẵn có

·         Chất lượng: Mức độ chính xác, ổn định hoặc tiêu chí đầu ra phải duy trì

·         An toàn và tuân thủ: Quy định, chính sách hoặc yêu cầu bắt buộc không được vi phạm

·         Phụ thuộc: Hệ thống, quy trình hoặc bên liên quan mà giải pháp phải tương thích

·         Điều kiện vận hành: Môi trường và tình huống thực tế trong đó giải pháp phải hoạt động

Ràng buộc không phải mục tiêu thứ hai. Chẳng hạn, “giảm thời gian xử lý” có thể là mục tiêu, trong khi “không làm giảm độ chính xác” là ràng buộc. Một phương án xử lý nhanh hơn nhưng tạo thêm sai sót không đáp ứng đầy đủ yêu cầu, dù đã đạt một phần mục tiêu.

Phân biệt ràng buộc bắt buộc và ưu tiên

Không phải mọi điều kiện đều có mức độ quan trọng giống nhau. Một số ràng buộc là bắt buộc: vi phạm chúng khiến phương án không thể chấp nhận. Những điều kiện khác chỉ thể hiện mức độ ưu tiên và có thể được cân nhắc khi xuất hiện đánh đổi.

Việc phân biệt này đặc biệt cần thiết khi hai yêu cầu xung đột. Ví dụ, thời gian triển khai rất ngắn có thể làm giảm khả năng xây dựng một phương án hoàn chỉnh ngay từ đầu. Khi đó, cần biết giới hạn thời gian là bắt buộc hay chỉ là mong muốn để có thể đánh giá đánh đổi đúng cách.

Chuyển mục tiêu và ràng buộc thành yêu cầu cụ thể

Sau khi xác định mục tiêu, khoảng cách và ràng buộc, cần chuyển chúng thành các phát biểu mô tả điều giải pháp phải bảo đảm, thay vì mô tả trước giải pháp sẽ được thiết kế như thế nào.

Một cách kiểm tra đơn giản là đặt câu hỏi cho từng yêu cầu:

1.    Yêu cầu này phục vụ mục tiêu nào?

2.    Nó xử lý khoảng cách hoặc nguyên nhân nào?

3.    Nó phản ánh ràng buộc nào?

4.    Có thể kiểm tra một phương án đáp ứng yêu cầu này hay không?

5.    Nếu loại bỏ yêu cầu, khả năng giải quyết đúng vấn đề có giảm hay không?

Ví dụ, từ mục tiêu “rút ngắn thời gian tiếp nhận yêu cầu của khách hàng” và ràng buộc “không làm mất thông tin cần thiết”, có thể hình thành yêu cầu rằng quy trình mới phải giảm thao tác tiếp nhận nhưng vẫn thu thập đủ dữ liệu bắt buộc để xử lý trường hợp.

Cách diễn đạt này giữ yêu cầu ở mức kết quả và điều kiện cần đáp ứng. Nó chưa ép buộc phải dùng biểu mẫu mới, phần mềm mới hay tự động hóa. Các phương án đó chỉ nên được đánh giá sau khi yêu cầu đã đủ rõ.

Kiểm tra yêu cầu trước khi dùng để lựa chọn giải pháp

Một tập hợp yêu cầu chưa hoàn thành chỉ vì đã được liệt kê. Chúng cần được kiểm tra để bảo đảm có thể dùng làm cơ sở đánh giá phương án.

Trước hết, mỗi yêu cầu phải cần thiết. Nếu không liên hệ được với mục tiêu, vấn đề hoặc ràng buộc, cần xem lại lý do tồn tại của nó.

Tiếp theo, yêu cầu phải rõ nghĩa. Những từ như “nhanh”, “tốt”, “thuận tiện” hay “hiệu quả” dễ tạo cách hiểu khác nhau nếu không xác định chúng biểu hiện qua kết quả nào.

Yêu cầu cũng cần có khả năng kiểm tra. Khi xem xét một phương án, phải có cơ sở kết luận nó đáp ứng hay không đáp ứng yêu cầu. Yêu cầu càng mơ hồ, việc lựa chọn giải pháp càng dễ phụ thuộc vào cảm nhận.

Cuối cùng, các yêu cầu phải được kiểm tra về tính khả thi và xung đột. Một tập hợp yêu cầu có thể gồm từng điều kiện hợp lý riêng lẻ nhưng không thể đồng thời đáp ứng trong nguồn lực hiện có. Khi xảy ra xung đột, cần quay lại mục tiêu và mức độ ưu tiên của ràng buộc để xác định điều gì thực sự bắt buộc và điều gì có thể điều chỉnh.

Tránh biến giải pháp dự kiến thành yêu cầu của vấn đề

Một sai lệch phổ biến là xác định yêu cầu bằng cách mô tả phương án đã được nghĩ đến trước. Khi đó, quá trình giải quyết vấn đề có thể trở thành việc chứng minh một giải pháp định sẵn thay vì tìm cách đáp ứng nhu cầu thực tế.

Ví dụ, nếu vấn đề là người dùng mất nhiều thời gian tìm thông tin, yêu cầu cốt lõi có thể là “người dùng phải truy cập được thông tin cần thiết với ít thao tác hơn”. “Xây dựng chatbot” chỉ là một phương án có thể xem xét. Nếu chatbot được đưa thẳng thành yêu cầu, những phương án đơn giản hoặc phù hợp hơn có thể bị loại bỏ mà chưa được đánh giá.

Ngoại lệ xuất hiện khi một công nghệ, nền tảng hoặc cách thực hiện thực sự là ràng buộc bắt buộc. Khi đó, nó có thể trở thành một phần của yêu cầu, nhưng lý do phải đến từ điều kiện thực tế của vấn đề chứ không phải sở thích đối với một giải pháp.

Một yêu cầu tốt phải truy ngược được về lý do tồn tại

Mỗi yêu cầu nên truy ngược được về ít nhất một trong ba nguồn: mục tiêu, khoảng cách cần khắc phục hoặc ràng buộc. Khả năng truy ngược này giúp loại bỏ các yêu cầu thừa và làm rõ cách xử lý khi các yêu cầu mâu thuẫn.

Nếu một yêu cầu tồn tại vì phục vụ mục tiêu chính, nó cần được bảo vệ khi đánh giá phương án. Nếu nó chỉ xuất phát từ một giả định chưa được chứng minh, cần kiểm tra lại. Nếu nó đến từ một ràng buộc bắt buộc, phương án vi phạm yêu cầu đó phải được loại dù có ưu điểm ở những mặt khác.

Nhờ vậy, tập hợp yêu cầu không còn là danh sách mong muốn rời rạc mà trở thành một hệ thống logic:

Vấn đề thực tế → Mục tiêu → Khoảng cách cần xử lý → Ràng buộc → Yêu cầu → Tiêu chí đánh giá giải pháp

Yêu cầu giải quyết vấn đề được xác định đúng khi chúng mô tả rõ kết quả phải đạt, thay đổi cần tạo ra và giới hạn phải tuân thủ, đồng thời mỗi yêu cầu đều có thể truy ngược về mục tiêu hoặc điều kiện thực tế của vấn đề. Cách xác định này giữ quá trình tập trung vào nhu cầu cần giải quyết thay vì khóa sớm vào một phương án cụ thể, đồng thời tạo cơ sở nhất quán để kiểm tra và so sánh các giải pháp sau đó.