Yêu cầu được ghi lại chưa có nghĩa mọi người đã hiểu giống nhau

“Em tưởng anh biết rồi”

Thành từng nghe câu này trong một buổi trao đổi nội bộ. Yêu cầu đã được nói, người nhận cũng đã bắt đầu làm, nhưng đến lúc kiểm tra thì hai bên đang chờ hai kết quả khác nhau.

Không ai cố tình bỏ qua trách nhiệm. Người giao việc mang theo nhiều bối cảnh nhưng chỉ nói phần họ nghĩ là hiển nhiên. Người nhận thấy một yêu cầu có vẻ đủ rõ và tự điền phần còn thiếu bằng kinh nghiệm của mình.

Yêu cầu đã xuất hiện trong cuộc họp, tin nhắn và công cụ quản lý công việc. Nó đã được ghi lại nhiều lần. Nhưng chưa có bước nào buộc hai bên xác nhận rằng họ đang nói về cùng một vấn đề, cùng một phạm vi và cùng một kết quả cần đạt.

Một yêu cầu có nơi lưu chưa chắc đã có cách hiểu chung. Điểm chuyển giao chỉ hoàn tất khi người giao và người nhận có thể kiểm tra cùng một kết quả.

Khoảng trống nằm ở điểm bàn giao

Khi yêu cầu chưa rõ, team thường bổ sung thêm công cụ: một trường mô tả dài hơn, một biểu mẫu mới, một cuộc họp hoặc AI để viết lại nội dung cho dễ đọc.

Những cách này giúp thu thập thông tin, nhưng không tự tạo ra sự đồng thuận. Một đoạn mô tả có thể đúng ngữ pháp, đủ các mục và vẫn để lại những cách hiểu khác nhau về:

• Vấn đề thật sự cần giải quyết.
• Kết quả nào được xem là hoàn thành.
• Phần nào nằm trong hoặc ngoài phạm vi.
• Ai chịu trách nhiệm thực hiện.
• Ai có quyền xác nhận kết quả.

Chi phí lớn nhất không nằm ở việc nhập thêm vài dòng. Nó xuất hiện khi người thực hiện làm đúng những gì đã được viết nhưng vẫn sai mục đích của người yêu cầu.

Yêu cầu cần một hợp đồng vận hành tối thiểu

Trong Intake, đầu vào có thể đến từ nhiều nguồn khác nhau. Trước khi trở thành công việc chính thức, yêu cầu được đưa về một cấu trúc tối thiểu:

Thành phần	Câu hỏi cần trả lời
Vấn đề	Điều gì đang không hoạt động hoặc cần thay đổi?
Kết quả mong đợi	Sau khi hoàn thành, điều gì phải khác đi?
Phạm vi	Phần nào được xử lý và phần nào chưa nằm trong yêu cầu?
Người chịu trách nhiệm	Ai tiếp tục đưa công việc đến kết quả?
Điều kiện hoàn thành	Bằng chứng nào cho thấy yêu cầu đã đạt?

Đây không phải là một biểu mẫu để điền cho đủ. Nó là hợp đồng vận hành tối thiểu giữa người giao, người nhận và người có quyền duyệt.

Nếu một thành phần chưa rõ, yêu cầu cần được giữ ở trạng thái chờ làm rõ. Việc tạo GitLab issue không nên biến một giả định thành cam kết chính thức.

Workflow xác nhận trước khi tạo việc

Thành tách việc ghi nhận yêu cầu khỏi việc cam kết thực hiện:

Đầu vào từ nhiều nguồn
    -> AI tạo bản yêu cầu có cấu trúc
    -> Làm lộ phần còn thiếu
    -> Người giao xác nhận mục đích và kết quả
    -> Người nhận xác nhận cách hiểu và phạm vi
    -> Người có trách nhiệm duyệt
    -> Tạo GitLab issue

Trong workflow này, một bản nháp dễ đọc chưa phải là công việc đã sẵn sàng. Nó chỉ là vật liệu để các bên cùng kiểm tra.

Có ba thời điểm cần phân biệt:

1. Đã ghi nhận: hệ thống đã giữ nội dung nguồn.
2. Đã hiểu và xác nhận: các bên đã thống nhất vấn đề, kết quả và phạm vi hiện tại.
3. Đã cam kết thành công việc: người có trách nhiệm đã duyệt để tạo GitLab issue.

Việc tách ba trạng thái giúp team biết đang thiếu thông tin, thiếu xác nhận hay thiếu quyết định. Nó cũng ngăn giao diện dùng một dấu “hoàn tất” cho những ý nghĩa khác nhau.

Vai trò của từng người

Shared understanding không có nghĩa mọi người phải cùng viết một tài liệu dài. Mỗi người chỉ cần giữ đúng trách nhiệm tại điểm bàn giao:

Vai trò	Trách nhiệm
Người giao yêu cầu	Xác nhận vấn đề, kết quả mong đợi và bối cảnh cần thiết
Người nhận	Nói rõ phần chưa hiểu và xác nhận phạm vi mình sẽ thực hiện
Người duyệt hoặc Project owner	Quyết định yêu cầu đã đủ điều kiện trở thành công việc chưa
AI	Cấu trúc đầu vào, chỉ ra phần thiếu và chuẩn bị bản nháp để kiểm tra
Hệ thống	Giữ phiên bản, lịch sử xác nhận, người chịu trách nhiệm và trạng thái

AI có thể làm câu chữ rõ hơn, nhưng không thể tự xác nhận ý định của người gửi. Khi dữ kiện chưa đủ, đầu ra đúng là một câu hỏi cần trả lời, không phải một bản mô tả tự tin hơn.

Khi yêu cầu thay đổi

Yêu cầu có thể thay đổi khi team học thêm trong quá trình làm. Workflow tốt không cố khóa mọi thứ ngay từ đầu. Nó làm rõ điều gì đã thay đổi, ai quyết định và kết quả mới được xác nhận ra sao.

Khi người dùng chỉnh bản AI đề xuất hoặc Project owner thay đổi phạm vi, hệ thống cần giữ phiên bản mới thay vì âm thầm ghi đè bản cũ. Người thực hiện phải biết mình đang làm theo phiên bản nào. GitLab issue và điều kiện hoàn thành cũng cần phản ánh quyết định hiện tại.

Lịch sử không dùng để tìm người có lỗi. Nó giúp team trả lời ba câu hỏi khi có khác biệt:

• Tại thời điểm bắt đầu, team đã thống nhất điều gì?
• Điều gì đã thay đổi sau đó?
• Ai đang chịu trách nhiệm cho quyết định hiện tại?

Failure mode cần kiểm soát

Failure mode	Điều xảy ra	Cách kiểm soát
Mô tả nghe rõ nhưng không nêu kết quả	Người nhận tự suy luận mục đích	Yêu cầu xác nhận kết quả mong đợi
Có vấn đề nhưng không có phạm vi	Công việc mở rộng trong lúc thực hiện	Ghi phần nằm trong và ngoài yêu cầu
Không có người xác nhận	Mỗi bên dùng một định nghĩa hoàn thành	Chỉ định người có quyền duyệt
AI tự điền phần còn thiếu	Giả định trở thành thông tin có vẻ chính thức	Hiển thị phần chưa chắc chắn dưới dạng câu hỏi
Nội dung thay đổi nhưng không giữ phiên bản	Người nhận tiếp tục làm theo thông tin cũ	Lưu phiên bản và yêu cầu xác nhận lại
Tạo GitLab issue quá sớm	Backlog chứa công việc chưa sẵn sàng	Tách trạng thái ghi nhận khỏi trạng thái được duyệt

Một công cụ tốt không loại bỏ hoàn toàn hiểu nhầm. Nó làm cho phần chưa thống nhất xuất hiện trước khi team bỏ nhiều thời gian thực hiện.

Bằng chứng nên kiểm tra

Số lượng yêu cầu được ghi nhận không chứng minh workflow tốt hơn. Chất lượng nằm ở điểm chuyển giao. Team có thể quan sát:

• Bao nhiêu yêu cầu phải hỏi lại sau khi người thực hiện đã bắt đầu.
• Bao nhiêu việc bị trả lại vì kết quả hoặc phạm vi chưa rõ.
• Khi yêu cầu được duyệt, người giao và người nhận có mô tả giống nhau về điều kiện hoàn thành không.
• Khi nội dung thay đổi, lý do, phiên bản và người quyết định có được giữ lại không.
• Có bao nhiêu GitLab issue được tạo khi vẫn thiếu owner hoặc tiêu chí hoàn thành.

Không cần đo tất cả ngay từ đầu. Chọn một loại yêu cầu thường gây làm lại và quan sát xem bước xác nhận có làm phần chưa rõ xuất hiện sớm hơn không.

Điều bạn có thể áp dụng

Chọn một yêu cầu gần nhất từng bị hiểu sai. Trước khi bàn về công cụ, hãy đặt cùng người giao và người nhận năm câu hỏi:

1. Vấn đề thật sự cần giải quyết là gì?
2. Kết quả nào phải xuất hiện khi công việc hoàn thành?
3. Phần nào nằm ngoài phạm vi lần này?
4. Ai chịu trách nhiệm thực hiện và ai xác nhận kết quả?
5. Bằng chứng nào sẽ được dùng để kiểm tra?

Nếu hai bên chưa thể trả lời giống nhau, yêu cầu chưa sẵn sàng để tự động hóa hoặc chuyển thành công việc chính thức. Điểm bắt đầu có thể chỉ là một bước xác nhận rõ ràng.

Phạm vi công bố

Bài viết mô tả mô hình trách nhiệm ở mức công khai. Nó không công bố nội dung yêu cầu, prompt nội bộ, schema chi tiết, dữ liệu khách hàng hoặc cấu hình GitLab riêng tư.