End User

Người ngồi trước màn hình gõ thật, tám tiếng một ngày, hai trăm lần một tuần cùng một thao tác. Đó là end user. Họ hiếm khi được mời vào buổi họp chốt yêu cầu, và gần như luôn là người đầu tiên phát hiện hệ thống mới bắt họ làm nhiều việc hơn hệ thống cũ.

Người ký hợp đồng quyết định dự án có được làm không. Người dùng cuối quyết định nó có được dùng không.

Customer vs End User vs Stakeholder

Ba nhóm này có thể trùng nhau. Ở sản phẩm nội bộ, người trả tiền chính là công ty của người dùng. Ở app tiêu dùng, khách hàng và người dùng cuối là một. Nhưng ở phần mềm doanh nghiệp thì chúng tách rời, và chỗ tách rời đó là chỗ dự án hay chết.

Ví dụ thực tế

7 giờ 30 sáng, quầy lễ tân một phòng khám đa khoa tư nhân: hàng chờ 15 người và điện thoại đổ liên tục. Chuỗi có 8 cơ sở, ngày thường tầm 213 lượt khám.

• Customer: chủ phòng khám. Người ký hợp đồng, trả tiền, nghiệm thu. Bác quan tâm doanh thu theo bác sĩ, chi phí thuốc và một dashboard xem được trên điện thoại.
• End user: hai bạn lễ tân và sáu bác sĩ. Lễ tân tiếp nhận bệnh nhân lúc cao điểm 7h30 sáng, hàng chờ 15 người, mỗi ca phải xong dưới 40 giây. Bác sĩ gõ chỉ định trong lúc bệnh nhân ngồi trước mặt.
• Stakeholder khác: bệnh nhân (chịu ảnh hưởng, chờ lâu hay nhanh là do hệ thống), kế toán, dược sĩ quầy thuốc, và cơ quan y tế nhận báo cáo định kỳ.

BA lấy yêu cầu chủ yếu từ chủ phòng khám, qua bốn buổi họp. Bác muốn ghi nhận thật đầy đủ: mỗi bệnh nhân nhập 14 trường, có cả nghề nghiệp và nguồn biết đến phòng khám, để báo cáo marketing sau này chuẩn.

Khi lên hệ thống, lễ tân mất trung bình 2 phút 40 giây cho mỗi bệnh nhân thay vì 40 giây. Hàng chờ dồn ra tới cửa. Ba tuần sau, hai bạn lễ tân quay lại dùng sổ giấy và tối muộn ngồi nhập bù. Dữ liệu nhập bù thì sai lệch, báo cáo doanh thu theo bác sĩ lệch theo, và chính bác chủ mất đúng cái mình cần nhất.

Vì sao chỉ nghe người ký hợp đồng thì hệ thống sẽ chết

Người ký hợp đồng biết mình muốn kết quả gì, nhưng thường không biết công việc hằng ngày diễn ra thế nào. Họ mô tả quy trình theo cách nó nên diễn ra, và bỏ qua ngoại lệ mà nhân viên đang xử lý bằng kinh nghiệm.

Hậu quả có ba dạng và dạng nào cũng đau:

1. Người dùng lách hệ thống. Nhập tạm cho xong, gõ "x" vào trường bắt buộc, dùng Excel song song. Dữ liệu bẩn từ ngày đầu.
2. Yêu cầu phát sinh muộn. Đến UAT, người dùng thật mới được sờ vào, và họ nêu ra 40 điều đáng ra phải biết từ tháng đầu. Lúc này sửa là CR, là tiền, là trễ hạn.
3. Hệ thống bị bỏ. Nặng nhất. Chi cả tỷ rồi vẫn chạy song song sổ giấy, và phần mềm dần chỉ còn được mở vào ngày làm báo cáo.

Cách phòng thì đơn giản: xin nửa buổi ngồi cạnh người dùng cuối lúc cao điểm, không hỏi gì, chỉ xem và bấm giờ. Mang con số về báo với người ký hợp đồng — "phương án này làm mỗi ca tiếp nhận mất thêm 2 phút, nhân với hơn hai trăm ca là bảy tiếng công mỗi ngày" — thì cuộc trò chuyện đổi hẳn tính chất.

Mẹo khi đi làm

Chia trường thông tin thành hai nhóm: bắt buộc lúc tiếp nhận, và bổ sung sau. Ở ví dụ trên, chỉ 5 trường cần nhập ngay, 9 trường còn lại để bác sĩ hoặc kế toán điền ở bước sau, khi không có ai đứng chờ. Cùng một lượng dữ liệu, khác nhau ở chỗ đặt gánh nặng vào lúc nào.

Và trong biên bản họp, luôn ghi rõ yêu cầu đến từ ai. Lúc mong muốn của chủ va vào thực tế của người dùng, bạn có cơ sở mở lại trao đổi thay vì tranh cãi bằng trí nhớ.