Cách xác nhận vấn đề đã được hiểu đầy đủ

Một vấn đề có thể xem là đủ điều kiện để chuyển sang thiết kế giải pháp khi người thực hiện có thể trả lời rõ: đang xảy ra điều gì, xảy ra ở đâu và trong điều kiện nào, bằng chứng nào cho thấy đó thực sự là vấn đề, nguyên nhân nào đã được xác định hoặc loại trừ, và cần đạt trạng thái nào để xem vấn đề là được xử lý.

Trước hết phải phân biệt vấn đề với biểu hiện của vấn đề

Một trong những sai lệch phổ biến nhất là lấy biểu hiện làm vấn đề thực sự. Ví dụ, “quy trình xử lý chậm” có thể chỉ là biểu hiện. Vấn đề cần xác nhận có thể nằm ở một bước kiểm tra dư thừa, dữ liệu đầu vào không đầy đủ, sự phụ thuộc giữa các bộ phận hoặc một điều kiện vận hành cụ thể.

Vì vậy, bước đầu tiên là mô tả hiện tượng một cách quan sát được thay vì vội gán nguyên nhân.

Có thể kiểm tra bằng các câu hỏi:

·         Điều gì đang xảy ra?

·         Hiện tượng nào có thể quan sát hoặc đo lường?

·         Nó khác với trạng thái mong đợi ở điểm nào?

·         Ai hoặc hệ thống nào thực sự bị ảnh hưởng?

·         Vấn đề xuất hiện trong trường hợp nào?

Nếu chưa tách được hiện tượng quan sát được khỏi giả thuyết về nguyên nhân, việc chuyển sang thiết kế giải pháp là quá sớm.

Phạm vi và điều kiện của vấn đề phải được xác định

Một vấn đề chỉ được hiểu đủ khi biết nó xảy ra trong phạm vi nào và không xảy ra ở đâu.

Cần xác định ít nhất:

·         Đối tượng hoặc quy trình bị ảnh hưởng

·         Thời điểm hoặc giai đoạn xuất hiện

·         Điều kiện khiến vấn đề xuất hiện

·         Mức độ hoặc tần suất xảy ra

·         Trường hợp ngoại lệ

·         Phạm vi không thuộc vấn đề

Điểm quan trọng là không biến một hiện tượng xảy ra trong một điều kiện cụ thể thành kết luận áp dụng cho toàn bộ hệ thống.

Chẳng hạn, nếu lỗi chỉ xuất hiện khi dữ liệu đầu vào thiếu một trường bắt buộc, thì “hệ thống thường xuyên xử lý sai dữ liệu” là một mô tả rộng hơn những gì bằng chứng cho phép. Phạm vi càng rõ, việc thiết kế giải pháp càng ít bị lệch.

Bằng chứng phải đủ để xác nhận đây thực sự là vấn đề

Mô tả của người dùng hoặc cảm nhận của một bên liên quan có thể là tín hiệu để phát hiện vấn đề, nhưng chưa nhất thiết đủ để xác nhận vấn đề.

Cần tìm bằng chứng phù hợp với loại vấn đề, chẳng hạn:

·         Dữ liệu quan sát

·         Số liệu đo lường

·         Nhật ký hoặc hồ sơ vận hành

·         Kết quả kiểm tra

·         Phản hồi từ người sử dụng

·         So sánh với tiêu chuẩn hoặc trạng thái kỳ vọng

·         Ví dụ thực tế có thể kiểm chứng

Bằng chứng cần trả lời được câu hỏi: “Dựa vào đâu để kết luận rằng khoảng cách này thực sự tồn tại?”

Nếu chỉ có nhận định như “quy trình này không hiệu quả”, cần tiếp tục xác định “không hiệu quả” được thể hiện bằng chỉ số, hiện tượng hoặc kết quả nào.

Bằng chứng cũng cần được gắn với đúng kết luận. Không phải cứ có nhiều dữ liệu là vấn đề đã được xác nhận; dữ liệu phải thực sự giúp chứng minh, giải thích hoặc giới hạn kết luận.

Nguyên nhân phải được kiểm tra, nhưng không nên giả định nguyên nhân quá sớm

Hiểu vấn đề không đồng nghĩa với việc phải biết ngay nguyên nhân cuối cùng. Tuy nhiên, trước khi thiết kế giải pháp cần biết nguyên nhân nào đã có bằng chứng hỗ trợ, nguyên nhân nào mới chỉ là giả thuyết và nguyên nhân nào đã được loại trừ.

Có thể phân loại:

·         Đã xác nhận: Có bằng chứng đủ mạnh để hỗ trợ

·         Đang giả thuyết: Có cơ sở nhưng chưa được kiểm chứng đầy đủ

·         Đã loại trừ: Đã có bằng chứng cho thấy không phải nguyên nhân phù hợp

·         Chưa biết: Chưa có đủ thông tin để kết luận

Cách phân loại này quan trọng vì một giải pháp được thiết kế trên nguyên nhân chưa được kiểm chứng có thể chỉ xử lý phần biểu hiện.

Nếu nguyên nhân chưa rõ, điều cần làm tiếp theo có thể vẫn là làm rõ hoặc kiểm chứng vấn đề, thay vì lập tức thiết kế giải pháp.

Cần kiểm tra các bên có đang hiểu cùng một vấn đề không

Một vấn đề có thể được mô tả bằng cùng một từ nhưng mang ý nghĩa khác nhau đối với từng người.

Ví dụ, “chất lượng thấp” có thể được hiểu là tỷ lệ lỗi cao đối với bộ phận vận hành, nhưng lại được hiểu là kết quả không đạt yêu cầu đối với khách hàng. Nếu không thống nhất cách hiểu, mỗi bên có thể tham gia thiết kế một giải pháp cho một vấn đề khác nhau.

Vì vậy, cần xác nhận:

·         Các bên đang dùng cùng định nghĩa về vấn đề

·         Cùng thống nhất đối tượng bị ảnh hưởng

·         Cùng hiểu phạm vi và điều kiện xảy ra

·         Cùng nhận diện trạng thái hiện tại

·         Cùng hiểu mức độ ảnh hưởng

·         Cùng phân biệt đâu là dữ kiện và đâu là giả định

Một phép kiểm tra hữu ích là yêu cầu một người khác mô tả lại vấn đề bằng ngôn ngữ của họ. Nếu hai mô tả khác nhau ở những điểm ảnh hưởng đến hướng giải quyết, vấn đề chưa được xác nhận đầy đủ.

Phải biết thế nào là “đã đủ” trước khi chuyển sang giải pháp

Xác nhận vấn đề không cần đạt trạng thái “biết mọi thứ”. Mục tiêu là đạt đủ thông tin để việc thiết kế giải pháp không còn phụ thuộc vào những giả định quan trọng chưa được kiểm chứng.

Có thể sử dụng một bộ kiểm tra ngắn:

1.    Problem: Có mô tả rõ điều đang xảy ra không?

2.    Gap: Có xác định được khoảng cách giữa hiện trạng và trạng thái mong đợi không?

3.    Scope: Có biết vấn đề xảy ra trong phạm vi và điều kiện nào không?

4.    Evidence: Có bằng chứng đủ để xác nhận vấn đề không?

5.    Cause: Các nguyên nhân quan trọng đã được phân biệt giữa xác nhận và giả thuyết chưa?

6.    Impact: Đã hiểu vấn đề ảnh hưởng đến đối tượng nào và theo cách nào chưa?

7.    Boundary: Đã biết những trường hợp không thuộc vấn đề chưa?

8.    Shared Understanding: Các bên liên quan có cùng cách hiểu về vấn đề không?

Nếu một câu trả lời quan trọng vẫn phụ thuộc vào giả định chưa kiểm chứng, chưa nên coi giai đoạn xác nhận vấn đề đã hoàn tất.

Dấu hiệu cho thấy chưa nên chuyển sang thiết kế giải pháp

Một số dấu hiệu cho thấy vấn đề vẫn chưa được hiểu đủ:

·         Vấn đề được mô tả chủ yếu bằng các từ định tính như “kém”, “chậm”, “không tốt”, “không hiệu quả” nhưng chưa có căn cứ cụ thể

·         Biểu hiện và nguyên nhân đang được dùng lẫn nhau

·         Phạm vi vấn đề chưa rõ

·         Các bên liên quan mô tả vấn đề theo những cách khác nhau

·         Chưa biết điều kiện nào làm vấn đề xuất hiện hoặc biến mất

·         Có nhiều giả thuyết nguyên nhân nhưng chưa biết giả thuyết nào được hỗ trợ

·         Không có bằng chứng đủ để phân biệt vấn đề thực tế với nhận định chủ quan

·         Giải pháp đã được đề xuất trước khi vấn đề được xác nhận

Đặc biệt, nếu nhóm bắt đầu tranh luận “nên dùng giải pháp nào” trong khi vẫn chưa thống nhất “đang giải quyết vấn đề gì”, thì cần quay lại bước xác nhận.

Vấn đề được hiểu đủ không phải khi nhóm đã có một mô tả nghe hợp lý, mà khi hiện tượng, phạm vi, điều kiện, bằng chứng, nguyên nhân, ảnh hưởng và ranh giới của vấn đề đã đủ rõ để các bên cùng hiểu một đối tượng cần giải quyết. Khi đó, thiết kế giải pháp mới có nền tảng đáng tin cậy; nếu còn một giả định quan trọng chưa được kiểm chứng, bước tiếp theo nên là xác nhận hoặc làm rõ vấn đề thay vì vội thiết kế giải pháp.