Mở đầu — vì sao bài này quan trọng
Hãy thử tưởng tượng bạn đang phỏng vấn một nhân viên kho. Bạn hỏi: "Anh xử lý đơn hàng như thế nào?" Anh ta trả lời rành mạch: "Em quét mã đơn, kiểm tra số lượng trên hệ thống, rồi đóng gói và in tem giao hàng." Nghe rất gọn gàng, đúng quy trình. Bạn ghi vào tài liệu, đội dev xây hệ thống theo đúng mô tả đó. Ba tháng sau go-live, tỷ lệ giao sai vẫn cao như cũ.
Vấn đề nằm ở đâu? Khi bạn xuống kho ngồi quan sát thực tế nửa ngày, bạn mới phát hiện: anh nhân viên không hề "kiểm tra số lượng trên hệ thống" như đã nói. Thực tế, màn hình hệ thống tải quá chậm trong giờ cao điểm, nên anh đã in sẵn một bảng Excel dán trên tường để tra cứu nhanh, và bảng Excel đó cập nhật thủ công mỗi sáng — thường lệch so với tồn kho thật.
Đây chính là lý do tồn tại của kỹ thuật Observation (quan sát) và Shadowing (đi kèm theo dõi) trong nghề BA. Có một khoảng cách rất lớn giữa cái người ta nói họ làm và cái họ thực sự làm. Khoảng cách đó không phải vì stakeholder nói dối — mà vì con người hợp lý hóa, đơn giản hóa, và quên mất những thao tác đã trở thành phản xạ. Observation là kỹ thuật elicitation duy nhất cho phép bạn nhìn thấy sự thật ấy bằng chính mắt mình, thay vì nghe lại qua lời kể.
Trong cả bộ kỹ thuật BABOK, observation đứng ở vị trí đặc biệt: nó bổ sung và kiểm chứng những gì các kỹ thuật khác như phỏng vấn hay workshop thu được. Một BA giỏi không bao giờ tin tuyệt đối vào lời kể; họ luôn muốn "thấy thực tế" ít nhất một lần trước khi chốt yêu cầu.
Khái niệm cốt lõi
Observation là gì?
Observation là kỹ thuật thu thập yêu cầu bằng cách trực tiếp xem người dùng thực hiện công việc trong môi trường làm việc thật của họ. Thay vì hỏi "Quy trình của anh thế nào?", bạn đến tận nơi, im lặng quan sát và ghi lại cách công việc thực sự diễn ra: từng cú click, từng tờ giấy, từng lần họ chuyển qua lại giữa các phần mềm, từng câu họ hỏi đồng nghiệp bên cạnh.
Shadowing là một dạng observation kéo dài — bạn "đi theo như cái bóng" của một người trong một khoảng thời gian (nửa ngày, một ngày, thậm chí một tuần), trải nghiệm trọn vẹn nhịp công việc của họ chứ không chỉ một tác vụ đơn lẻ.
Hai kiểu quan sát: Passive và Active
Có hai cách tiếp cận chính, và BA cần chủ động chọn đúng kiểu cho từng tình huống.
Passive observation (quan sát thụ động): Bạn đứng/ngồi lặng lẽ, không can thiệp, không hỏi gì trong lúc người dùng làm việc. Mọi thắc mắc bạn ghi lại và để dành hỏi sau. Ưu điểm là bạn thấy được nhịp làm việc tự nhiên nhất, không làm gián đoạn. Nhược điểm: có những thao tác bạn không hiểu tại sao họ làm, và phải đoán.
Active observation (quan sát chủ động): Bạn vừa quan sát vừa đặt câu hỏi ngay lúc đó — "Tại sao bước này chị lại mở thêm cửa sổ kia?", "Cái nút này chị bấm để làm gì vậy?". Ưu điểm: hiểu sâu ngay tức thì. Nhược điểm: làm gián đoạn công việc, và đôi khi khiến người dùng "diễn" theo kiểu sách vở chứ không tự nhiên.
Một biến thể nâng cao là Contextual Inquiry — mô hình "thầy trò" (master-apprentice): bạn đóng vai người học việc, người dùng đóng vai thầy hướng dẫn. Cách này rất mạnh để khai thác kiến thức ngầm (tacit knowledge).
Vì sao observation bắt được thứ phỏng vấn không bao giờ thấy
Thứ nhất — bắt được workaround. Workaround là những "lối tắt" người dùng tự nghĩ ra để vượt qua giới hạn của hệ thống hiện tại: bảng Excel dán tường, ghi chú dán màn hình, sao chép dữ liệu thủ công giữa hai phần mềm, gọi điện xác nhận thay vì dùng tính năng có sẵn. Người dùng hiếm khi báo cáo workaround vì với họ đó là "chuyện hiển nhiên", hoặc vì họ ngại bị đánh giá là làm sai quy trình. Nhưng mỗi workaround chính là một yêu cầu chưa được đáp ứng đang gào thét.
Thứ hai — thấy môi trường, distraction và tooling thật. Người dùng làm việc trong điều kiện gì? Màn hình bao nhiêu inch? Có bị điện thoại reo liên tục không? Có phải vừa làm vừa tiếp khách không? Ánh sáng, tiếng ồn, việc đứng hay ngồi — tất cả ảnh hưởng đến cách thiết kế giải pháp. Một app nhập liệu cho nhân viên giao hàng đứng giữa nắng, dùng một tay cầm điện thoại, sẽ phải thiết kế hoàn toàn khác với app cho nhân viên văn phòng ngồi hai màn hình.
Thứ ba — đo được thời gian và nhịp thật. Người dùng nói "việc này nhanh thôi", nhưng quan sát cho thấy mất 8 phút và 14 cú click. Con số thật là dữ liệu vàng cho việc ưu tiên cải tiến.
Tình huống thực tế
Ví dụ 1 — Chuỗi cà phê và "ca cao đặc biệt"
Một chuỗi cà phê tại TP.HCM (giả định, khoảng 40 cửa hàng) muốn nâng cấp hệ thống POS để tăng tốc order giờ cao điểm. Qua phỏng vấn quản lý, BA nhận được mô tả quy trình chuẩn: khách gọi món → thu ngân chọn món trên POS → khách thanh toán → in bill cho barista pha chế. Nghe rất trơn tru.
BA quyết định shadowing một thu ngân tại cửa hàng đông nhất trong khung 7h–9h sáng. Kết quả phát hiện ba điều mà không buổi phỏng vấn nào nhắc tới:
- Khoảng 20% khách quen gọi món bằng "tên riêng" tự đặt: "cho chị ly cũ", "ca cao đặc biệt như hôm qua". Thu ngân phải nhớ và tự diễn giải sang menu thật. POS không có cách lưu món yêu thích, nên mỗi lần phải bấm tùy chỉnh 5–6 bước.
- Khi khách trả tiền mặt, máy POS đặt xa quầy, thu ngân phải xoay người, thối tiền, rồi xoay lại — mất trung bình 12 giây mỗi giao dịch tiền mặt.
- Barista và thu ngân giao tiếp bằng cách... hét qua tiếng máy xay, vì bill in ra thường bị trễ 15–20 giây.
Ví dụ 2 — Bệnh viện và tờ giấy nhỏ trong túi áo blouse
Một bệnh viện tư triển khai hệ thống bệnh án điện tử (EMR). Sau 2 tháng, điều dưỡng phản ánh "hệ thống chậm, khó dùng" nhưng không nói cụ thể được. BA dùng passive observation, đi theo một điều dưỡng suốt ca trực buổi sáng, chỉ ghi chép, không hỏi.
Quan sát phát hiện: mỗi khi đi buồng bệnh, điều dưỡng ghi chỉ số sinh hiệu (huyết áp, mạch, nhiệt độ) vào một tờ giấy nhỏ gập trong túi áo blouse, vì máy tính chỉ đặt ở quầy trực, không thể mang theo. Cuối mỗi vòng, họ quay về quầy nhập lại toàn bộ vào EMR. Tức là dữ liệu được nhập hai lần: một lần tay, một lần máy. Riêng việc nhập lại này ngốn khoảng 40 phút mỗi ca.
Đáng chú ý hơn: tờ giấy đôi khi thất lạc hoặc chữ viết vội bị nhầm, dẫn đến sai số sinh hiệu trên hệ thống — một rủi ro y khoa nghiêm trọng mà không ai từng "báo cáo".
Bài học: Lời than "hệ thống chậm" thật ra là vấn đề về thiết bị di động và luồng nhập liệu tại giường bệnh, không phải về tốc độ phần mềm. Giải pháp đúng là trang bị máy tính bảng/thiết bị cầm tay cho điều dưỡng nhập tại chỗ. Chỉ có observation mới tách bạch được triệu chứng ("chậm") khỏi nguyên nhân gốc (workaround giấy + nhập đôi).
Ví dụ 3 — Kho hàng e-commerce và "đường đi của đôi chân"
Một công ty thương mại điện tử ở Đông Nam Á muốn cải thiện tốc độ soạn hàng (picking) trong kho. BA kết hợp shadowing với một kỹ thuật nhỏ: vẽ lại "đường đi" thực tế của nhân viên soạn hàng trên sơ đồ kho (spaghetti diagram — sơ đồ mì spaghetti, vẽ tất cả các tuyến di chuyển).
Sau khi đi theo 3 nhân viên trong 2 giờ, BA nhận ra: các mặt hàng bán chạy nhất lại được xếp ở góc xa nhất kho, khiến nhân viên đi tới đi lui liên tục. Đường đi vẽ ra chằng chịt như tô mì. Một nhân viên đi trung bình 14 km mỗi ca chỉ để soạn hàng.
Bài học: Ở đây, giải pháp lớn nhất thậm chí không nằm ở phần mềm, mà ở việc sắp xếp lại vị trí hàng hóa theo tần suất bán (slotting). Nhưng yêu cầu phần mềm cũng lộ ra: hệ thống cần gợi ý tuyến soạn hàng tối ưu thay vì liệt kê theo thứ tự ngẫu nhiên. Observation giúp BA nhìn vấn đề ở cả tầng nghiệp vụ lẫn tầng hệ thống — điều mà ngồi phòng họp không bao giờ thấy được.
Hướng dẫn từng bước
Bước 1 — Xác định mục tiêu và đối tượng quan sát. Trước khi đi, hãy viết rõ: bạn muốn trả lời câu hỏi gì? Quan sát ai, làm tác vụ nào, vào thời điểm nào? Đừng quan sát chung chung "xem họ làm việc thế nào" — hãy nhắm vào quy trình cụ thể bạn đang phân tích.
Bước 2 — Xin phép và giải thích đúng cách. Đây là bước cực kỳ quan trọng về mặt con người. Hãy nói rõ với người được quan sát: bạn đến để hiểu công việc và cải tiến công cụ cho họ, không phải để đánh giá hay giám sát hiệu suất. Nếu người dùng cảm thấy bị soi, họ sẽ "diễn" theo sách vở và bạn mất hết giá trị. Một câu mở đầu tốt: "Em đến học cách anh/chị làm để thiết kế công cụ tốt hơn, anh/chị cứ làm bình thường như mọi ngày giúp em nhé."
Bước 3 — Chọn passive hay active và chuẩn bị mẫu ghi chép. Với quy trình lạ và phức tạp, nên bắt đầu bằng passive để thấy nhịp tự nhiên. Chuẩn bị sẵn một mẫu ghi chú có các cột: thao tác / thời gian / công cụ dùng / điểm vướng / câu hỏi để dành.
Bước 4 — Quan sát và ghi chép có cấu trúc. Ghi lại cả "what" (họ làm gì) lẫn "why" (nếu hiểu được lý do). Đặc biệt chú ý: những lần họ rời khỏi hệ thống (mở Excel, dùng giấy, gọi điện), những lần họ ngập ngừng/lúng túng, những lần họ hỏi đồng nghiệp. Đó là các điểm vàng. Ghi cả con số: bao nhiêu click, bao nhiêu giây, bao nhiêu lần lặp.
Bước 5 — Hỏi làm rõ sau buổi quan sát (debrief). Để dành các câu hỏi "tại sao" và hỏi sau khi họ làm xong, để không cắt ngang. Đây cũng là lúc bạn kiểm chứng cách diễn giải của mình có đúng không.
Bước 6 — Tổng hợp và xác nhận lại (playback). Viết lại quy trình thực tế bạn quan sát được, kèm các workaround và điểm vướng, rồi trình bày lại cho người dùng và stakeholder để họ xác nhận: "Đúng là quy trình của em diễn ra như vầy phải không?". Bước xác nhận này tránh việc bạn hiểu sai một hành vi đơn lẻ thành quy luật.
Lỗi thường gặp & mẹo
Lỗi 1 — Quan sát một người, một lần rồi tổng quát hóa. Một nhân viên có thể có thói quen riêng không đại diện cho số đông. Hãy quan sát ít nhất 2–3 người, ở các cửa hàng/chi nhánh/ca trực khác nhau, trước khi kết luận đây là "quy trình chung".
Lỗi 2 — Hiệu ứng Hawthorne: bị quan sát thì làm khác đi. Khi biết có người nhìn, người ta tự nhiên làm cẩn thận và đúng bài hơn bình thường. Mẹo: dành 15–20 phút đầu để họ quen với sự hiện diện của bạn; giá trị thật thường lộ ra ở nửa sau buổi quan sát khi họ đã thư giãn và quay lại thói quen thật.
Lỗi 3 — Chỉ chọn giờ rảnh, ngày đẹp. Nếu bạn quan sát quầy cà phê lúc 3h chiều vắng khách, bạn sẽ bỏ lỡ toàn bộ vấn đề giờ cao điểm. Hãy chủ động chọn cả thời điểm bận rộn và thời điểm bình thường, vì nhiều yêu cầu chỉ xuất hiện khi hệ thống chịu tải cao.
Lỗi 4 — Can thiệp quá nhiều, biến observation thành phỏng vấn. Nếu cứ vài giây lại hỏi, bạn không còn quan sát hành vi tự nhiên nữa. Hãy kiềm chế, để dành câu hỏi cho phần debrief.
Lỗi 5 — Quên ghi lại môi trường vật lý. Nhiều BA chỉ chăm chăm vào màn hình phần mềm mà quên ghi: tiếng ồn, số màn hình, tư thế làm việc, gián đoạn từ điện thoại/khách. Những yếu tố này quyết định lớn đến thiết kế giải pháp.
Mẹo vàng — Đóng vai người học việc. Nếu được phép, hãy xin tự tay làm thử công việc dưới sự hướng dẫn của người dùng. Khoảnh khắc bạn vấp ở chính chỗ họ vấp, bạn sẽ hiểu pain point sâu sắc hơn ngàn lời mô tả.
Mẹo về đạo đức và sự riêng tư. Tôn trọng dữ liệu nhạy cảm (thông tin khách hàng, bệnh nhân). Đừng chụp màn hình có dữ liệu thật mà chưa được phép. Luôn ẩn danh khi đưa quan sát vào tài liệu.
Bài tập thực hành
Bài tập 1 — Lập kế hoạch quan sát. Chọn một quy trình quen thuộc quanh bạn (nhân viên quán ăn lên đơn, thu ngân siêu thị, lễ tân khách sạn). Viết một bản kế hoạch observation nửa trang gồm: mục tiêu, đối tượng, thời điểm chọn (và lý do), passive hay active, và 5 câu hỏi "để dành" cho phần debrief.
Bài tập 2 — Quan sát thực địa và bắt workaround. Thực hiện 30 phút quan sát quy trình ở bài 1. Lập bảng ghi chép theo các cột: thao tác / thời gian / công cụ / điểm vướng. Mục tiêu cụ thể: tìm ra ít nhất hai workaround — những lúc người dùng rời khỏi quy trình/hệ thống chuẩn để tự xoay xở. Ghi rõ họ làm gì và (nếu đoán được) tại sao.
Bài tập 3 — Chuyển quan sát thành yêu cầu. Từ các workaround và điểm vướng đã ghi, viết ra 3 yêu cầu (requirements) tương ứng. Với mỗi yêu cầu, ghi rõ: vấn đề quan sát được → yêu cầu đề xuất → bằng chứng (con số/tình huống bạn đã thấy). Đây chính là cách biến "thấy thực tế" thành đầu ra có giá trị cho dự án.
Tóm tắt
Observation và shadowing là kỹ thuật elicitation cho phép BA nhìn thấy sự thật mà lời kể không bao giờ truyền tải đủ. Con người mô tả công việc theo cách họ nghĩ mình làm, nhưng thực tế đầy rẫy workaround, gián đoạn và thói quen ngầm — và chính những thứ đó thường là nguồn yêu cầu quan trọng nhất.
Hãy nhớ ba giá trị cốt lõi: observation bắt được workaround không ai báo cáo, cho thấy môi trường và công cụ thật, và đo được thời gian/nhịp thật bằng con số. Chọn đúng kiểu passive hay active, xin phép đúng cách để người dùng làm tự nhiên, quan sát nhiều người ở nhiều thời điểm, cảnh giác với hiệu ứng Hawthorne, và luôn xác nhận lại (playback) trước khi chốt.
Một câu để khắc cốt ghi tâm cho cả sự nghiệp BA: đừng tin tuyệt đối vào điều stakeholder nói cho đến khi bạn đã một lần thấy tận mắt họ làm. Khoảng cách giữa "nói" và "làm" chính là nơi những yêu cầu giá trị nhất đang ẩn mình chờ bạn phát hiện.