Chọn phần mềm cho nhóm: thử việc thật rồi hãy chốt

Buổi giới thiệu phần mềm kết thúc, cả nhóm gần như muốn đăng ký ngay. Màn hình đẹp, báo cáo có màu, kéo thả rất mượt. Nhưng đến lúc thử nhập một đơn khách đổi địa chỉ giữa chừng, chẳng ai biết sửa ở đâu. Trong ví dụ này, nhóm của Duy đang chọn công cụ quản lý đơn hàng. Phần demo làm họ thích; việc thật mới cho thấy công cụ có hợp hay không.

Chọn phần mềm cho nhóm nên bắt đầu bằng những việc đang làm mỗi ngày. Một đợt thử nhỏ, có người dùng thật và tiêu chí rõ, sẽ giúp bạn quyết định chắc hơn. Quan trọng là nhìn cả lúc xử lý bình thường lẫn lúc có chuyện lệch kế hoạch.

Đem cùng một việc ra thử

Duy chọn ba tình huống: nhận đơn mới, sửa đơn và bàn giao đơn chưa xong cho ca sau. Cả ba đều xảy ra thường xuyên trong cửa hàng. Anh không lấy một ví dụ quá đẹp chỉ có vài dòng thông tin. Nếu công cụ chỉ chạy mượt với trường hợp đơn giản nhất, nhóm vẫn chưa biết mình sẽ dùng nó ra sao vào ngày đông khách.

Trước khi mở bản dùng thử, nhóm ghi kết quả mong đợi cho từng việc. Với đơn mới, người nhận phải thấy đủ món, địa chỉ và ghi chú. Với đơn sửa, người đóng hàng phải biết thông tin nào vừa thay đổi. Với bàn giao, ca sau phải tìm được việc còn chờ mà không gọi lại người đã nghỉ.

Những kết quả này giúp buổi thử bớt lan man. Khi có người hào hứng với một tính năng khác, Duy ghi lại để xem sau. Câu hỏi chính vẫn là “đơn này đã đi hết quy trình chưa?”. Nếu nhóm chưa thống nhất cách làm hiện tại, nên đọc lại phần chuẩn bị quy trình trước khi dùng phần mềm. Công cụ khó sửa được một việc mà mỗi người đang hiểu một kiểu.

Đem cùng bộ dữ liệu mẫu sang các công cụ đang cân nhắc. Dữ liệu nên giả lập, có đủ trường cần thiết nhưng không chứa thông tin riêng của khách thật. Giữ cùng số đơn, cùng lỗi và cùng yêu cầu bàn giao. Như vậy, nhóm đang so cách xử lý cùng một việc, thay vì cho công cụ này bài dễ còn công cụ kia bài khó.

Người thử cũng nên có vai trò khác nhau. Duy thao tác khá nhanh, nhưng chị phụ trách đóng hàng mới là người cần đọc ghi chú suốt ca. Một bạn chỉ dùng điện thoại lại phát hiện nút quan trọng bị khuất trên màn hình nhỏ. Nếu chỉ hỏi người quản trị, nhóm sẽ bỏ qua trải nghiệm của phần lớn người dùng.

Ở lượt đầu, cho mọi người làm bằng hướng dẫn sẵn có. Ghi lại chỗ phải hỏi, chỗ chọn nhầm và chỗ chưa hiểu tên gọi. Sau đó mới hướng dẫn thêm rồi thử lại. Phân biệt được lỗi do chưa quen và vướng mắc vẫn tồn tại sau khi đã học sẽ giúp đánh giá công bằng hơn.

Đừng chỉ bấm đồng hồ. Một thao tác nhanh nhưng dễ bỏ sót địa chỉ có thể tạo thêm việc phía sau. Duy ghi cả thời gian, lỗi gặp và số lần phải nhờ người khác. Những dòng ghi chú như “không thấy đơn đã sửa” hữu ích hơn điểm số “giao diện: tám trên mười” mà không có lý do đi kèm.

Tính cả lúc chuyển sang dùng

Giá thuê bao mới là phần dễ nhìn thấy. Nhóm còn phải chuyển dữ liệu, tạo tài khoản, phân quyền và học cách dùng. Duy liệt kê từng việc, ai phụ trách và cần chuẩn bị gì. Nếu một người phải dành nhiều buổi để nhập lại đơn cũ, thời gian ấy cũng nằm trong chi phí chuyển đổi.

Trước tiên, kiểm tra dữ liệu nào thật sự cần mang sang. Các đơn đang xử lý thường cần hơn toàn bộ lịch sử nhiều năm. Dữ liệu cũ có thể giữ ở nơi tra cứu riêng nếu quy trình cho phép. Nhập mọi thứ ngay từ đầu vừa tốn công vừa có thể mang theo các tên khách trùng, trạng thái cũ và cột không còn dùng.

Thử nhập một phần nhỏ rồi mở từng loại bản ghi để đối chiếu. Tên có giữ dấu tiếng Việt không? Ngày có bị hiểu nhầm tháng? Ghi chú dài có mất đoạn cuối? Công việc làm sạch bảng dữ liệu trước khi nhập giúp giảm lỗi, nhưng vẫn cần kiểm tra kết quả bên trong phần mềm.

Phân quyền cũng cần thử bằng tài khoản đúng vai trò. Người đóng hàng cần đọc địa chỉ, nhưng chưa chắc cần xem mọi báo cáo của cửa hàng. Người mới vào nhóm không nên được quyền xóa dữ liệu chỉ vì đó là thiết lập mặc định. Duy lập vài tài khoản thử để nhìn thấy đúng màn hình mà đồng nghiệp sẽ dùng.

Tiếp theo là câu hỏi ít vui nhưng rất đáng hỏi: nếu không dùng nữa thì lấy dữ liệu ra thế nào? Hãy thử xuất một bộ mẫu, mở file và kiểm tra nội dung. Một nút “xuất dữ liệu” chưa đảm bảo bạn lấy được cả ghi chú, tệp đính kèm hoặc lịch sử cần giữ. Chỗ nào chưa rõ thì hỏi nhà cung cấp bằng trường hợp cụ thể.

Trong ngày chuyển đổi, ai hỗ trợ khi có lỗi? Nhóm của Duy chọn một buổi ít đơn để thử, có người theo dõi và có cách quay lại quy trình cũ. Họ ghi rõ thời điểm bắt đầu, nơi lưu bản dữ liệu trước đó và người quyết định dừng. Nhờ vậy, mọi người không phải tự ứng biến giữa lúc khách đang chờ.

Chốt bằng điều nhóm quan sát được

Sau đợt thử, Duy gom ghi nhận vào một bảng ngắn. Mỗi dòng là một yêu cầu, kèm kết quả và ví dụ. “Bàn giao đơn: ca sau tìm thấy trong danh sách chờ” là bằng chứng cụ thể. “Có vẻ chuyên nghiệp” chỉ là cảm giác, có thể ghi thêm nhưng không nên thay cho kết quả sử dụng.

Chia yêu cầu thành phần bắt buộc và phần có thì tốt. Với cửa hàng này, không bỏ sót đơn sửa là bắt buộc. Đổi màu bảng theo sở thích chỉ là điểm cộng. Nếu công cụ thiếu việc cốt lõi, những tính năng đẹp mắt còn lại không tự bù được. Cách chia này cũng giúp nhóm tránh chấm điểm trung bình rồi chọn nhầm.

Khi hai công cụ đều đáp ứng phần bắt buộc, xem nhóm sẽ sống cùng công cụ nào dễ hơn. Người dùng có tự làm được việc thường ngày không? Việc hỗ trợ có dồn hết vào một người không? Mỗi tuần phải sửa dữ liệu thủ công bao nhiêu lần? Đây là những câu hỏi gần với cuộc sống của nhóm sau ngày đăng ký.

Ghi cả điều chưa kiểm chứng. Nếu mới thử mười đơn, đừng kết luận công cụ chắc chắn xử lý tốt ngày cao điểm. Nếu chưa thử tích hợp, ghi “chưa thử” thay vì mặc định sẽ chạy. Nhóm có thể chọn triển khai trong phạm vi nhỏ thêm một thời gian trước khi chuyển toàn bộ.

Cuối buổi, Duy chốt một quyết định có lý do: dùng thử cho một ca, theo dõi đơn sửa và kiểm lại sau một tuần. Mọi người biết đang chọn gì, còn nghi ngại điều gì và khi nào xem lại. Cảm giác hào hứng từ buổi demo vẫn còn, nhưng giờ nó đi cùng những việc nhóm đã tự tay làm được.