Cách xác định giả định trong thiết kế giải pháp

Một giả định tốt cần trả lời được bốn câu hỏi: đang giả định điều gì, dựa trên cơ sở nào, nếu sai thì ảnh hưởng ra sao và sẽ kiểm chứng bằng cách nào. Đây là điểm quan trọng vì một giả định sai có thể làm sai lệch yêu cầu, cơ chế thiết kế, phạm vi giải pháp hoặc tiêu chí đánh giá ngay từ đầu.

Giả định trong thiết kế giải pháp là gì và vì sao phải xác định rõ

Giả định xuất hiện khi người thiết kế phải ra quyết định trong điều kiện thông tin chưa đầy đủ. Chẳng hạn, nhóm thiết kế có thể tạm xem rằng người dùng sẽ có quyền truy cập vào một hệ thống hiện hữu, dữ liệu đầu vào có cấu trúc ổn định hoặc một quy trình nghiệp vụ sẽ không thay đổi trong phạm vi triển khai.

Điểm cần phân biệt là giả định mô tả điều đang được xem là đúng để làm cơ sở thiết kế, còn yêu cầu mô tả điều giải pháp phải đáp ứng và bằng chứng dùng để xác nhận liệu giả định đó có đúng hay không.

Một giả định chỉ có giá trị khi nó gắn với một quyết định thiết kế cụ thể. Nếu loại bỏ giả định đó mà thiết kế vẫn không thay đổi, giả định có thể không có ý nghĩa thực tế và không cần được đặt ở vị trí trọng tâm.

Có thể kiểm tra nhanh một giả định bằng ba câu hỏi:

·         Giả định này đang làm thay đổi quyết định thiết kế nào

·         Nếu giả định sai, phần nào của giải pháp sẽ bị ảnh hưởng

·         Có cách nào kiểm chứng giả định trước khi quyết định được khóa lại hay không

Nếu không trả lời được các câu hỏi này, giả định chưa đủ rõ để sử dụng làm cơ sở thiết kế.

Cần xác định giả định nào trước khi thiết kế giải pháp

Không nên lập một danh sách giả định chung chung rồi đưa vào tài liệu. Cần xác định những giả định có quan hệ trực tiếp với các quyết định thiết kế quan trọng.

Một cách tiếp cận phù hợp là rà soát theo các nhóm sau:

Giả định về người dùng và nhu cầu

Đây là các giả định liên quan đến đối tượng sử dụng, hành vi, năng lực, mục tiêu và điều kiện sử dụng giải pháp.

Ví dụ, thiết kế có thể dựa trên giả định rằng người dùng đã quen với một quy trình hiện tại hoặc có thể thực hiện một thao tác nhất định mà không cần hỗ trợ bổ sung.

Giả định cần được viết cụ thể thay vì dùng các nhận định như “người dùng dễ sử dụng” hoặc “người dùng có nhu cầu cao”. Những cách diễn đạt này khó kiểm chứng vì không xác định rõ điều kiện và tiêu chí đánh giá.

Giả định về dữ liệu và đầu vào

Cần xác định dữ liệu nào được xem là có sẵn, đủ chính xác, đủ đầy đủ và có thể truy cập trong điều kiện thực tế.

Ví dụ:

·         Dữ liệu đầu vào có tồn tại trong hệ thống nguồn

·         Dữ liệu có cấu trúc phù hợp với phương án xử lý

·         Dữ liệu được cập nhật trong khoảng thời gian cần thiết

·         Các trường dữ liệu quan trọng không bị thiếu ở mức làm thay đổi kết quả

Giả định về hệ thống và môi trường

Nhóm này bao gồm các điều kiện kỹ thuật, hạ tầng, tích hợp, hiệu năng hoặc môi trường vận hành mà giải pháp đang dựa vào.

Ví dụ, một phương án có thể phụ thuộc vào khả năng kết nối với hệ thống hiện hữu. Khi đó, khả năng tích hợp không nên chỉ được xem là “điều kiện kỹ thuật”, mà phải được xác định thành một giả định có thể kiểm chứng.

Giả định về quy trình và tổ chức

Giải pháp có thể phụ thuộc vào việc một quy trình hiện tại tiếp tục được duy trì, một vai trò vẫn tồn tại hoặc một đơn vị có thể thực hiện một nhiệm vụ mới.

Nếu thay đổi tổ chức hoặc quy trình có thể làm phương án không còn phù hợp, đây là giả định cần được ghi nhận và theo dõi.

Giả định về phạm vi và ràng buộc

Cần làm rõ những giới hạn đang được xem là cố định, chẳng hạn phạm vi người dùng, thời gian triển khai, nguồn lực, ngân sách, quy định hoặc yêu cầu tương thích.

Các giả định này đặc biệt quan trọng vì chúng xác định không gian mà giải pháp được phép thiết kế.

Một giả định tốt phải được viết như thế nào

Giả định nên được viết thành một mệnh đề có đối tượng, điều kiện và trạng thái được giả định, thay vì chỉ ghi một từ khóa.

Cấu trúc thực tế có thể là:

Trong [điều kiện/phạm vi], giả định rằng [điều được xem là đúng], vì [cơ sở hiện có]. Nếu giả định này không đúng, [phần bị ảnh hưởng] sẽ cần được xem xét lại.

Ví dụ yếu:

Người dùng có khả năng sử dụng hệ thống

Ví dụ rõ hơn:

Trong phạm vi triển khai hiện tại, giả định rằng người dùng đã có quyền truy cập vào hệ thống hiện hữu và có thể thực hiện các thao tác xác thực cơ bản; nếu điều kiện này không đúng, thiết kế quy trình truy cập và hướng dẫn sử dụng sẽ phải được điều chỉnh

Cách viết thứ hai tốt hơn vì nó làm rõ:

·         Đối tượng nào đang được giả định

·         Điều kiện nào làm giả định có hiệu lực

·         Phần nào của thiết kế phụ thuộc vào giả định

·         Điều gì có thể thay đổi nếu giả định sai

Một giả định cũng nên phân biệt rõ với một sự thật đã được xác nhận. Nếu đã có bằng chứng đáng tin cậy chứng minh một điều kiện là đúng trong phạm vi áp dụng, không cần tiếp tục gọi nó là giả định.

Làm thế nào để đánh giá mức độ quan trọng của một giả định

Không phải mọi giả định đều có mức rủi ro như nhau. Có thể ưu tiên kiểm chứng dựa trên mức độ phụ thuộc của thiết kế và hậu quả nếu giả định sai.

Một giả định đáng ưu tiên khi có một hoặc nhiều đặc điểm:

·         Là cơ sở trực tiếp cho một quyết định thiết kế quan trọng

·         Nếu sai sẽ khiến phải thay đổi kiến trúc hoặc phương án chính

·         Khó đảo ngược sau khi giải pháp đã được triển khai

·         Có khả năng xảy ra nhưng hiện chưa có đủ bằng chứng

·         Có thể tạo ảnh hưởng lớn đến chi phí, tiến độ, chất lượng hoặc khả năng vận hành

·         Liên quan đến điều kiện bên ngoài mà nhóm thiết kế không kiểm soát hoàn toàn

Có thể phân loại đơn giản theo ma trận Tác động × Mức độ chưa chắc chắn.

Điểm quan trọng là không nên đánh giá một giả định chỉ dựa trên cảm giác “có vẻ hợp lý”. Một giả định có thể rất hợp lý nhưng vẫn cần kiểm chứng nếu hậu quả của việc sai là lớn.

Kiểm chứng giả định trong thiết kế giải pháp như thế nào

Kiểm chứng không nhất thiết phải là một nghiên cứu lớn. Phương pháp nên tương xứng với mức độ quan trọng và độ không chắc chắn của giả định.

Kiểm tra tài liệu và dữ liệu hiện có

Phù hợp khi giả định liên quan đến quy trình, yêu cầu, dữ liệu hoặc điều kiện đã có trong tổ chức.

Mục tiêu là tìm bằng chứng trực tiếp thay vì tiếp tục dựa vào nhận định của nhóm thiết kế.

Phỏng vấn hoặc xác nhận với bên liên quan

Phù hợp với giả định về nhu cầu, quy trình, vai trò hoặc cách sử dụng.

Cần tránh biến việc hỏi ý kiến thành bằng chứng duy nhất cho những vấn đề có thể kiểm tra bằng dữ liệu thực tế.

Phân tích dữ liệu

Phù hợp khi giả định có thể được kiểm tra bằng số liệu, tỷ lệ, tần suất, thời gian xử lý, mức sử dụng hoặc các chỉ số vận hành.

Khi một nhận định có thể đo lường, nên ưu tiên tiêu chí định lượng thay vì các mô tả như “thường xuyên”, “cao”, “thấp” hoặc “hiệu quả”.

Prototype hoặc thử nghiệm nhỏ

Phù hợp khi chưa thể xác nhận giả định bằng tài liệu hoặc dữ liệu sẵn có.

Thay vì triển khai toàn bộ giải pháp, có thể tạo một phiên bản giới hạn để kiểm tra đúng điều kiện đang gây bất định.

Kiểm thử điều kiện biên

Phù hợp khi giả định liên quan đến giới hạn vận hành hoặc ngoại lệ.

Không chỉ cần hỏi “giả định có đúng không”, mà cần xác định đúng trong điều kiện nào và bắt đầu không còn đúng từ đâu.

Sau khi kiểm chứng, giả định phải được xử lý thế nào

Kết quả kiểm chứng không chỉ có “đúng” hoặc “sai”. Trong thiết kế thực tế, một giả định có thể rơi vào nhiều trạng thái khác nhau.

Đã xác nhận: Có đủ bằng chứng để sử dụng điều kiện đó làm cơ sở thiết kế

Bị bác bỏ: Bằng chứng cho thấy giả định không đúng; phương án phụ thuộc vào giả định phải được thiết kế lại

Chưa xác định: Chưa đủ bằng chứng để kết luận; giả định vẫn phải được theo dõi và không nên bị đối xử như sự thật

Có điều kiện: Giả định chỉ đúng trong một phạm vi hoặc điều kiện nhất định

Trường hợp “có điều kiện” đặc biệt quan trọng. Thay vì ghi:

Hệ thống đáp ứng yêu cầu hiệu năng

nên xác định rõ điều kiện mà yêu cầu đó được xem là đáp ứng, chẳng hạn phạm vi tải, loại tác vụ hoặc môi trường vận hành liên quan.

Khi một giả định chưa được kiểm chứng nhưng quyết định thiết kế vẫn phải tiếp tục, cần ghi nhận điều kiện phụ thuộc và phương án xử lý nếu giả định thất bại. Như vậy, nhóm thiết kế không vô tình biến một giả định tạm thời thành một sự thật cố định.

Cách quản lý giả định để tránh biến chúng thành rủi ro tiềm ẩn

Giả định nên được quản lý như một phần của logic thiết kế, không chỉ như một danh sách phụ ở cuối tài liệu.

Mỗi giả định quan trọng nên có tối thiểu:

·         Mã hoặc tên nhận diện

·         Nội dung giả định

·         Cơ sở hình thành

·         Quyết định thiết kế phụ thuộc

·         Mức độ chưa chắc chắn

·         Tác động nếu giả định sai

·         Cách kiểm chứng

·         Người hoặc nhóm chịu trách nhiệm kiểm chứng

·         Trạng thái kiểm chứng

·         Điều kiện hoặc giới hạn áp dụng

·         Hành động nếu giả định không được xác nhận

Trình tự quản lý nên là:

Xác định → Gắn với quyết định thiết kế → Đánh giá tác động → Xác định bằng chứng → Kiểm chứng → Cập nhật trạng thái → Điều chỉnh thiết kế nếu cần

Cách tiếp cận này giúp phân biệt rõ giả định chưa được xác nhận với ràng buộc đã được xác nhận và quyết định thiết kế đã được chốt.

Điểm cốt lõi là không cần cố loại bỏ mọi giả định khỏi thiết kế giải pháp. Điều quan trọng hơn là nhận diện đúng giả định có ảnh hưởng đến quyết định, diễn đạt chúng thành các mệnh đề có điều kiện, xác định bằng chứng cần thiết và kiểm chứng trước khi mức độ phụ thuộc trở nên khó đảo ngược. Một giả định chỉ nên được xem là cơ sở chắc chắn của giải pháp khi phạm vi, điều kiện và bằng chứng hỗ trợ nó đã đủ rõ.