User Research cho người Finance — Từ Finance/Kế Toán sang BA: Lộ Trình Chuyển Đổi

Mở đầu — vì sao bài này quan trọng

Khi tôi nói với học viên Finance rằng BA phải làm "User Research" (nghiên cứu người dùng), phản ứng thường gặp nhất là một cái nhíu mày: "Em làm kế toán, em có phải dân thiết kế hay marketing đâu mà đi phỏng vấn người dùng?" Đây là một trong những rào cản tâm lý lớn nhất khiến người Finance e ngại nghề BA — họ nghĩ User Research là việc của UX designer, của người làm sản phẩm, không phải của người quen ngồi với con số và chứng từ.

Sự thật là: bạn đã làm User Research suốt nhiều năm mà không gọi nó bằng cái tên đó. Mỗi lần bạn ngồi với phòng kinh doanh để hỏi tại sao họ không nộp chứng từ đúng hạn, mỗi lần bạn phỏng vấn thủ kho để hiểu vì sao tồn kho trên sổ lệch với thực tế, mỗi lần bạn truy ngược một con số bất thường để tìm ra gốc rễ ở khâu nhập liệu — đó chính là nghiên cứu người dùng dưới một hình thức rất gần với BA.

Bài này không bàn về User Research nói chung theo sách giáo khoa UX (việc đó các bài khác và các khóa UX sẽ làm). Nhiệm vụ riêng của Bài 9 là chỉ cho bạn cách tận dụng đúng vốn kinh nghiệm Finance/Kế toán để làm User Research cho một BA: bạn vốn mạnh ở đâu, đâu là những thói quen Finance cần điều chỉnh, và làm thế nào để biến kỹ năng "điều tra số liệu" thành kỹ năng "điều tra nhu cầu người dùng". Đây là một trong những kỹ năng giúp bạn nổi bật so với BA mới ra trường, vì bạn đã có sẵn sự nhạy bén với con người trong quy trình.

Khái niệm cốt lõi

User Research trong vai trò BA thực chất là gì

Trong ngữ cảnh BA, User Research là quá trình tìm hiểu một cách có hệ thống về người dùng (user) và các bên liên quan (stakeholder) để hiểu họ thực sự cần gì, làm việc ra sao, đang vướng ở đâu — trước khi viết yêu cầu cho hệ thống. Mục tiêu không phải để "chiều" người dùng, mà để xây dựng giải pháp giải đúng vấn đề thật, thay vì giải vấn đề mà ai đó tưởng tượng ra.

Điểm cần phân biệt ngay: User Research của BA khác với khảo sát thị trường của marketing và khác với usability test của UX designer. BA quan tâm nhiều đến nghiệp vụ, quy trình, và nỗi đau vận hành — đúng vùng đất bạn đã sống trong Finance. Khi một BA hỏi "chị làm bước đối soát công nợ này thế nào, mất bao lâu, hay sai ở đâu?", đó là một câu hỏi nghiệp vụ rất Finance.

Vốn liếng Finance bạn mang sẵn vào User Research

Có bốn thế mạnh mà người Finance hầu như ai cũng có, và chúng "dịch" thẳng sang kỹ năng nghiên cứu người dùng:

Thứ nhất, tư duy truy nguyên (root-cause). Kế toán quen với việc một con số lệch là phải tìm cho ra nguyên nhân gốc, không dừng ở triệu chứng. Trong User Research, kỹ thuật quan trọng nhất là "5 Whys" — hỏi "tại sao" liên tục để đào xuống nhu cầu thật. Người Finance làm điều này theo bản năng. Khi người dùng nói "tôi cần một nút xuất Excel", BA giỏi sẽ hỏi tiếp "để làm gì", "xuất xong chị làm gì với nó" — y hệt cách bạn truy một bút toán bất thường.

Thứ hai, hiểu quy trình end-to-end. Bạn biết một chứng từ đi qua tay ai, ở khâu nào dễ nghẽn. Nên khi phỏng vấn, bạn không hỏi rời rạc mà hỏi theo dòng chảy công việc, dễ phát hiện điểm đứt gãy giữa các phòng ban.

Thứ ba, sự nhạy với "ngoại lệ". Finance luôn để ý case bất thường, trường hợp đặc biệt, ngoại lệ phê duyệt. Trong User Research, chính những ngoại lệ ("à, nhưng riêng khách VIP thì tụi em làm tay") mới là vàng — vì hệ thống thường chết ở các edge case này.

Thứ tư, sự tỉ mỉ khi ghi chép và đối chiếu. Bạn quen ghi lại đầy đủ, đối chiếu nhiều nguồn để khớp số. Kỹ năng này biến thành khả năng tổng hợp findings (phát hiện) sạch sẽ, có dẫn chứng, thay vì kết luận cảm tính.

Ba thói quen Finance cần điều chỉnh

Vốn mạnh đi kèm điểm mù. Tôi muốn bạn ý thức ba điều:

Đừng phán xét đúng/sai như khi soát chứng từ. Trong User Research, mục tiêu là hiểu hành vi người dùng, kể cả khi họ làm "sai quy trình". Một thủ quỹ ghi tay sổ riêng song song với phần mềm không phải là kẻ làm sai — đó là tín hiệu phần mềm đang thiếu thứ gì đó. Tư duy kiểm soát của bạn dễ khiến bạn vội kết luận "người dùng làm ẩu" và bỏ lỡ insight.

Đừng giả định người dùng giống bạn. Bạn giỏi Excel, nhưng nhân viên bán hàng ngoài cửa hàng có thể sợ con số. Cái dễ với bạn có thể là rào cản với họ.

Đừng hỏi câu dẫn dắt (leading question). Finance quen hỏi để xác nhận giả thuyết. User Research cần câu hỏi mở để khám phá. Hỏi "Chị thấy báo cáo hiện tại khó dùng đúng không?" sẽ khác hẳn "Chị mô tả giúp em cách chị làm báo cáo này hàng tháng?".

Tình huống thực tế

Tình huống 1 — Kế toán công nợ chuyển BA tại một chuỗi bán lẻ

Chị Hương, cựu kế toán công nợ tại một chuỗi bán lẻ mỹ phẩm khoảng 40 cửa hàng ở TP.HCM, được giao làm BA cho dự án thay phần mềm quản lý đơn hàng. Ban giám đốc yêu cầu rất rõ: "Làm sao để rút ngắn thời gian đối soát doanh thu cuối ngày của các cửa hàng."

Thay vì nhận yêu cầu rồi viết luôn spec, chị Hương dùng đúng phản xạ Finance: đi xuống thực địa 5 cửa hàng, ngồi quan sát nhân viên đóng ca cuối ngày (kỹ thuật contextual inquiry — quan sát người dùng trong chính bối cảnh làm việc của họ). Chị phát hiện một điều mà báo cáo không bao giờ nói: nhân viên cửa hàng đối soát tiền mặt rồi chụp màn hình gửi Zalo cho kế toán vùng, vì phần mềm cũ chạy chậm vào giờ cao điểm. Con số "đối soát mất 45 phút" thực ra gồm 30 phút chờ phần mềm và 15 phút thao tác Zalo thủ công.

Bài học rút ra: nếu chỉ tin vào yêu cầu của sếp ("rút ngắn đối soát"), giải pháp có thể là "thêm nút đối soát nhanh". Nhưng User Research cho thấy nỗi đau thật là hiệu năng và thói quen làm việc song song qua Zalo. Chị Hương đề xuất chế độ offline và đồng bộ sau — một yêu cầu mà không buổi họp phòng máy lạnh nào nghĩ ra. Đây là sức mạnh của việc xuống tận nơi, điều người Finance vốn quen làm khi đi kiểm kê.

Tình huống 2 — Cựu kế toán tại một fintech cho vay tiêu dùng

Anh Tuấn, từng làm kế toán tại một công ty fintech cho vay tiêu dùng (giả định gọi là "VayNhanh"), chuyển sang BA cho đội xây dựng quy trình thu hồi nợ. Đội sản phẩm muốn xây dashboard nhắc nợ tự động cho nhân viên collection (thu hồi nợ).

Anh Tuấn tổ chức phỏng vấn 1-1 với 8 nhân viên collection, mỗi buổi 30 phút, và áp dụng 5 Whys. Khi một bạn nói "tụi em cần lọc khách theo số ngày quá hạn", anh hỏi tới "tại sao", "rồi anh gọi ai trước". Đào ba lớp, anh phát hiện nhân viên giỏi không gọi theo số ngày quá hạn, mà theo khả năng liên lạc được và thiện chí trả — một loại tri thức ngầm (tacit knowledge) nằm trong đầu người giỏi, chưa hề được số hóa. Anh cũng nhận ra mình suýt rơi vào bẫy "giả định người dùng giống mình": là kế toán, anh nghĩ ưu tiên theo số tiền và số ngày là hợp lý nhất, nhưng thực địa nói khác.

Kết quả: thay vì làm dashboard sắp xếp theo ngày quá hạn như yêu cầu ban đầu, anh đề xuất thêm trường "lịch sử liên lạc thành công" và điểm thiện chí. Sau 2 tháng triển khai, tỷ lệ thu hồi nhóm nợ 30–60 ngày của đội tăng khoảng 11%.

Bài học rút ra: User Research giúp lôi tri thức ngầm của người dùng giỏi ra ánh sáng, biến nó thành business rule cho hệ thống. Người Finance, vốn quen "hỏi cho ra nguồn gốc con số", có lợi thế tự nhiên ở kỹ thuật đào sâu này — miễn là chịu gác lại giả định của bản thân.

Tình huống 3 — Phỏng vấn nhầm đối tượng tại một doanh nghiệp sản xuất

Bạn Mai, cựu kế toán tổng hợp tại một công ty sản xuất bao bì ở Bình Dương, làm BA cho dự án số hóa quy trình đề nghị thanh toán. Mai phỏng vấn rất kỹ — nhưng chỉ phỏng vấn các kế toán viên, vì đó là nhóm cô thấy quen thuộc và dễ nói chuyện. Cô bỏ qua người thực sự khởi tạo đề nghị thanh toán: các trưởng bộ phận mua hàng và quản đốc phân xưởng.

Khi hệ thống chạy thử, các quản đốc — vốn không rành máy tính, hay làm việc ngoài xưởng — không chịu nhập liệu, dẫn đến tắc nghẽn ngay đầu quy trình. Dự án phải làm lại phần giao diện cho nhóm này.

Bài học rút ra: một lỗi rất "Finance" là chỉ nghiên cứu nhóm người dùng mình thấy thoải mái và am hiểu. Stakeholder mapping (xác định đủ các bên liên quan) phải đi trước User Research. Phải hỏi: ai khởi tạo, ai phê duyệt, ai chịu ảnh hưởng, ai là người dùng "miễn cưỡng" nhất? Người dùng khó tiếp cận nhất thường là người quyết định thành bại của hệ thống.

Hướng dẫn từng bước

Đây là quy trình User Research gọn mà tôi khuyên người Finance áp dụng cho mỗi tính năng hoặc quy trình cần phân tích:

Xác định mục tiêu nghiên cứu. Viết một câu duy nhất: "Tôi cần hiểu điều gì?" Ví dụ: "Hiểu vì sao quy trình duyệt chi mất trung bình 4 ngày." Mục tiêu mơ hồ sẽ cho ra phỏng vấn lan man.

Lập bản đồ stakeholder. Liệt kê mọi vai trò chạm vào quy trình: người khởi tạo, người thực hiện, người phê duyệt, người nhận kết quả, người bị ảnh hưởng. Đánh dấu nhóm khó tiếp cận hoặc dễ bị bỏ quên (như tình huống 3). Tận dụng hiểu biết quy trình end-to-end của bạn ở bước này.

Chọn phương pháp phù hợp. Ba phương pháp lõi cho BA: phỏng vấn 1-1 (đào sâu nhu cầu), quan sát thực địa / contextual inquiry (thấy hành vi thật, lộ ra khoảng cách giữa "nói" và "làm"), và khảo sát (kiểm chứng trên số đông). Người Finance nên ưu tiên phỏng vấn và quan sát vì hợp với thế mạnh đào sâu của bạn.

Soạn bộ câu hỏi mở. Chuẩn bị 6–10 câu, ưu tiên dạng "Anh/chị mô tả giúp em cách...", "Lần gần nhất việc này gặp trục trặc là khi nào?". Tránh câu yes/no và câu dẫn dắt. Để dành 5 Whys cho lúc cần đào sâu.

Thực hiện và ghi chép trung lập. Nghe nhiều hơn nói (quy tắc 80/20). Ghi nguyên văn từ ngữ người dùng, không "biên tập" theo giả định của bạn. Xin phép ghi âm nếu được. Tuyệt đối không phán xét tại chỗ.

Tổng hợp và tìm pattern. Gom findings, nhóm theo chủ đề, tìm điểm lặp lại giữa nhiều người. Tách rõ điều người dùng nói họ cần và vấn đề thật bạn quan sát được — hai thứ này thường khác nhau. Dùng kỹ năng đối chiếu nhiều nguồn của Finance ở đây.

Chuyển findings thành đầu vào cho yêu cầu. Mỗi nỗi đau (pain point) nên gắn với một nhu cầu, làm cơ sở cho yêu cầu hệ thống ở các bước sau của quy trình BA. Luôn truy được "yêu cầu này đến từ phát hiện nào, của ai".

Lỗi thường gặp & mẹo

Hỏi giải pháp thay vì hỏi vấn đề. Người dùng hay nói "tôi muốn nút X". Đừng chép lại y nguyên; hỏi vấn đề đằng sau. Mẹo: mỗi khi nghe một "giải pháp", hỏi thêm một lần "để giải quyết điều gì ạ?".

Tin lời nói hơn hành vi. Người dùng thường mô tả quy trình "lý tưởng" khác với việc họ làm thật. Mẹo: kết hợp ít nhất một buổi quan sát thực địa với phỏng vấn — đây cũng là phản xạ "đi kiểm kê tận nơi" của Finance.

Phán xét kiểu soát chứng từ. Thấy người dùng làm tắt, đừng vội nghĩ "làm sai". Hãy coi mỗi cách làm tắt là một tín hiệu hệ thống đang thiếu.

Phỏng vấn quá ít hoặc thiên lệch nhóm dễ tiếp cận. Mẹo: với mỗi vai trò quan trọng, phỏng vấn 3–8 người; dừng khi không còn nghe được điều mới (bão hòa thông tin).

Dùng câu dẫn dắt. Mẹo: trước buổi phỏng vấn, đọc lại bộ câu hỏi và gạch bỏ mọi câu đã gợi ý sẵn câu trả lời.

Quên xin con số định lượng. Đây lại là điểm mạnh của bạn — đừng quên hỏi "việc này mất bao lâu", "tần suất bao nhiêu lần/tuần", "sai sót khoảng mấy %". Số liệu giúp ưu tiên đúng vấn đề.

Bài tập thực hành

Dịch kinh nghiệm cũ: Viết ra 3 lần trong nghề Finance bạn đã thực sự làm User Research mà không gọi tên (ví dụ: đi hỏi kho để tìm nguyên nhân lệch tồn). Với mỗi lần, ghi rõ bạn đã dùng kỹ thuật gì (truy nguyên, quan sát, hỏi mở).

Lập stakeholder map: Chọn một quy trình bạn quen (duyệt chi, đối soát công nợ, khóa sổ). Vẽ sơ đồ tất cả các vai trò chạm vào quy trình đó, đánh dấu nhóm dễ bị bỏ quên nhất.

Soạn kịch bản phỏng vấn: Viết 8 câu hỏi mở để phỏng vấn người dùng về quy trình ở bài 2. Sau đó tự rà soát và sửa mọi câu dẫn dắt hoặc câu yes/no.

Thực hành 5 Whys: Tìm một người quen làm nghiệp vụ bất kỳ, hỏi họ về một việc họ làm hàng ngày, và đào ít nhất 4 lớp "tại sao". Ghi lại xem nhu cầu thật ở lớp cuối có khác với câu trả lời ban đầu không.

Tóm tắt

User Research không phải lãnh địa xa lạ của dân thiết kế — nó là một dạng "điều tra nhu cầu" mà người Finance đã làm bằng bản năng suốt nhiều năm. Vốn liếng của bạn rất rõ: tư duy truy nguyên gốc rễ, hiểu quy trình end-to-end, nhạy với ngoại lệ, và thói quen ghi chép, đối chiếu tỉ mỉ. Tất cả "dịch" thẳng sang các kỹ thuật cốt lõi như 5 Whys, contextual inquiry và phỏng vấn đào sâu.

Điều bạn cần luyện là gác lại ba thói quen Finance dễ thành điểm mù: phán xét đúng/sai, giả định người dùng giống mình, và hỏi câu dẫn dắt. Hãy nhớ ba bài học từ các tình huống trên: xuống tận nơi để thấy nỗi đau thật (chị Hương), đào sâu để moi tri thức ngầm và gác giả định cá nhân (anh Tuấn), và lập stakeholder map đầy đủ trước khi phỏng vấn để không bỏ sót người dùng quan trọng nhất (bạn Mai). Làm chủ User Research, bạn sẽ viết được những yêu cầu giải đúng vấn đề thật — và đó chính là điều phân biệt một BA giỏi với một người chỉ chép lại yêu cầu.