Customer

Chữ "khách hàng" trong một dự án IT hay bị dùng lẫn lộn tới mức nguy hiểm. Trong cùng một buổi họp, PM nói "khách yêu cầu" là đang nhắc đến công ty thuê mình, còn PO nói "khách hàng" là đang nói về người tiêu dùng dùng app. Hai nghĩa, hai nhóm người, hai loại yêu cầu. Trước khi bàn tiếp, cần thống nhất đang nói về ai.

Customer là bên trả tiền và nghiệm thu. Điều họ muốn chưa chắc trùng với điều người dùng cần.

Ai là khách trong một dự án outsourcing

Chuỗi này ở VN có khi dài ba tầng và mỗi tầng lại là khách của tầng trước:

1. Công ty phần mềm nhận dự án.
2. Khách hàng trực tiếp: một ngân hàng, một chuỗi bán lẻ, hoặc một công ty môi giới ở nước ngoài.
3. Khách của khách: người tiêu dùng cuối dùng sản phẩm.

BA ngồi ở tầng một thường chỉ được tiếp xúc với tầng hai, đôi khi chỉ với một đầu mối duy nhất bên tầng hai. Cái bẫy nằm ở chỗ: đầu mối đó có thể đang diễn giải lại yêu cầu của phòng ban khác, và diễn giải sai. Bạn ghi biên bản đầy đủ, làm đúng như được nói, mà sản phẩm vẫn không dùng được — vì thông tin đã méo qua hai lần truyền.

Cách xử lý: xin nói chuyện trực tiếp với người dùng nghiệp vụ ít nhất một lần cho mỗi module, dù chỉ 30 phút và có đầu mối ngồi cùng. Nếu bị từ chối, ghi rõ giả định vào tài liệu: "Yêu cầu này được xác nhận bởi anh A, chưa trao đổi trực tiếp với bộ phận vận hành." Câu đó cứu bạn về sau.

Khách hàng nội bộ

Với dự án làm cho chính công ty mình — ERP nội bộ, hệ thống nhân sự, cổng thông tin — thì không có hợp đồng nào cả, nhưng vẫn có khách hàng: phòng ban đề xuất và cấp trên duyệt ngân sách. Cách làm việc khác hẳn:

Chính vì thiếu ràng buộc bên ngoài mà với khách nội bộ, ma trận RACI và biên bản chốt phạm vi lại càng cần thiết.

Ví dụ thực tế

Cổng đặt hàng chạy được hai tháng thì phòng kinh doanh báo lên một con số khó chịu: 6 trên 10 đại lý đang bị khóa tài khoản. Đây là dự án cho một nhà phân phối vật liệu xây dựng, 870 đại lý ở các tỉnh; khách hàng của dự án là ban giám đốc, còn người ngồi đặt hàng là các chủ đại lý.

Ban giám đốc yêu cầu bắt buộc đăng nhập bằng tài khoản và mật khẩu mạnh, đổi mật khẩu 90 ngày một lần, theo chuẩn bảo mật nội bộ. Hợp lý trên giấy tờ.

Thực tế: chủ đại lý phần lớn ngoài 45 tuổi, đặt hàng bằng điện thoại, và trước đó vẫn gọi cho nhân viên kinh doanh để đặt. Quên mật khẩu, bị khóa, thế là họ quay lại gọi điện. Nhân viên kinh doanh trở thành người nhập hộ, đúng thứ mà dự án muốn loại bỏ.

Giải pháp sau đó: đăng nhập bằng số điện thoại và OTP qua Zalo, giữ nguyên yêu cầu bảo mật nhưng đổi cách thực hiện. Phương án này đã có người đề xuất ngay từ buổi phân tích đầu tiên, nhưng bị gạt vì "khách đã yêu cầu như vậy rồi".

Lỗi hay gặp

• Làm thư ký cuộc họp. Nhận yêu cầu xong là chuyển thẳng cho dev, không hỏi lại một câu nào.
• Đánh đồng khách với người dùng. Chiều khách tới mức người dùng cuối bỏ hệ thống thì cuối cùng khách cũng không hài lòng.
• Chỉ có một đầu mối duy nhất. Người đó nghỉ việc là dự án mất trí nhớ.
• Sợ nói không. Từ chối kèm dữ liệu và phương án thay thế thì khách nghe. Từ chối bằng cảm tính thì không.

Người trả tiền cũng chưa chắc là người duyệt, và chỗ này ít ai để ý. Có dự án người trả tiền là tập đoàn mẹ, người duyệt là giám đốc công ty con, hai bên không cùng mục tiêu, và BA đứng giữa hai bộ yêu cầu mà vẫn tưởng mình đang phục vụ một khách.

Một câu hỏi đáng dùng trong buổi kick-off: hết năm đầu tiên chạy hệ thống, anh chị nhìn vào con số nào để biết dự án này đáng tiền. Câu trả lời cho bạn biết khách thật sự mua cái gì.