Sản phẩm làm ra xịn thật, giao diện đẹp long lanh, nhưng không ai dùng, anh em thủ kho vẫn lén ghi sổ tay, còn dữ liệu trên phần mềm thì sai bét nhè. Đó là bài học đắt giá từ một dự án ERP ở nhà máy cơ khí, và gốc của nó nằm ở chỗ BA chỉ ghi lại đúng lời Giám đốc nói, “làm cho anh cái phần mềm quản lý kho thông minh hơn, xịn hơn”, mà không ai đào xem phía sau câu đó là nhu cầu gì.
đừng tin ngay những gì họ nói#
Yêu cầu của stakeholder giống tảng băng trôi, BA chỉ nhìn phần nổi thì sớm muộn cũng đâm đầu vào đá. Mình hay tách nó ra ba lớp cho dễ hình dung:
| Lớp yêu cầu | Ví dụ |
|---|---|
| Stated (nói ra) | “Anh muốn có nút Xuất Excel báo cáo tồn kho.” |
| Implied (ngầm định) | “File Excel phải giữ nguyên định dạng để in ra ký, số liệu phải khớp thực tế từng phút.” Họ coi đó là hiển nhiên nên không nói. |
| Real needs (nhu cầu thật) | Họ cần nút Excel vì sếp bắt báo cáo hàng tuần, và họ phải cộng trừ thủ công mất cả ngày thứ Bảy. |
Nhìn đến lớp thứ ba mới thấy giải pháp thật chẳng phải cái nút Excel, mà là một dashboard tự cập nhật số liệu lên tivi của sếp, khỏi báo cáo, khỏi in ấn. Còn cứ mù quáng làm theo lời nói thì kiểu gì cũng dính scope creep, sửa đi sửa lại không dứt.
mấy kỹ thuật moi tin, phiên bản nhà máy#
Lý thuyết có cả rổ kỹ thuật, nhưng mang xuống nhà máy thì phải linh hoạt, mấy cái dưới đây là những cái mình thấy hợp với môi trường sản xuất nhất.
Phỏng vấn, nhưng đừng hỏi “anh muốn gì?” Hỏi trúng nỗi đau của họ, kiểu “khó khăn lớn nhất khiến anh hay bị trễ đơn hàng là gì?”, lúc đó họ mới kể ra vấn đề thật như vật tư về chậm, máy hỏng vặt, và đấy là mỏ vàng của BA.
Quan sát, đi Gemba. Xuống xưởng đứng cạnh cô công nhân đóng gói, để ý xem vì sao cô ấy phải dừng máy để ghi vào tờ giấy nhàu nát, rồi nhìn lên máy thấy dán đầy giấy note “Lưu ý: mã hàng X hay bị kẹt”. Đó chính là yêu cầu ngầm định mà không ai nói ra.
Workshop, một sàn đấu vật có trọng tài. Khi ông Kho với ông Mua hàng cãi nhau chuyện hàng về trễ thì lùa hết vào một phòng, BA làm facilitator, cho họ cãi chán rồi thống nhất một quy trình chung, chứ gặp riêng từng người thì người nào cũng đổ lỗi cho người kia, dân dự án gặp chuyện này suốt.
Phân tích tài liệu. Mượn cuốn sổ tay, mượn file Excel lủng củng của kế toán xưởng về đọc, sẽ thấy quy trình đang chạy thật khác xa quy trình ISO trên giấy.
Benchmarking. Sếp gửi link video “nhà máy thông minh của Đức” rồi bảo “làm cho anh giống thế này” thì đừng hoảng, cứ phân tích xem video đó giải quyết vấn đề gì, rồi hỏi thẳng “anh tâm đắc nhất đoạn nào, robot tự hành hay hệ thống báo cáo?”.
Còn brainstorming, survey, prototyping thì để dành bài khác.
công cụ là bạc, tư duy mới là vàng#
Kỹ thuật thì học được, nhưng thứ làm sản phẩm có hồn là thấu cảm. Đặt mình vào chỗ người công nhân đứng hết ca rã rời chân tay, mình sẽ tự hiểu vì sao giao diện cần nút bấm to, dễ nhìn, thao tác càng ít càng tốt.
Thứ còn lại là tư duy phản biện, mà công cụ đơn giản nhất là cứ hỏi “tại sao” cho đến khi chạm gốc. Số liệu sai, tại sao? Do nhập sai. Tại sao nhập sai? Do mã hàng dài quá khó nhớ. Thế tại sao không dùng mã vạch? Đến đây mới chạm vào root cause.
đi tìm sự thật#
Khơi gợi yêu cầu không phải điền vào chỗ trống, nó là hành trình đi tìm sự thật, và BA cần chuyển từ người hỏi “cần gì?” thành người tư vấn “nên làm gì để giải quyết vấn đề?”. Làm ra một phần mềm ERP không khó, làm ra cái phần mềm mà anh em dưới xưởng chịu vứt cuốn sổ tay đi để dùng mới khó.
Muốn đọc tiếp thì có bài 3 nguyên tắc sống còn để lấy yêu cầu và BA trong nhà máy: 6 món võ.
