Trước khi mở phần mềm nội bộ cho cả nhóm, thử những gì?

Buổi giới thiệu phần mềm mới diễn ra rất mượt. Người hướng dẫn tạo một yêu cầu, bấm duyệt rồi chuyển sang trạng thái hoàn tất. Cả nhóm nghĩ sáng mai có thể dùng luôn. Nhưng tới lúc nhân viên ca tối đăng nhập, họ không thấy nút cần bấm. Một yêu cầu bị gửi hai lần vì người dùng tưởng lần đầu chưa lưu.

Giả sử đây là phần mềm theo dõi yêu cầu nội bộ của một công ty nhỏ. Bản demo cho thấy luồng thuận lợi, còn những chuyện như thiếu quyền, nhập sai hay đổi ca chưa được thử. Mở cho cả nhóm ngay sẽ khiến mọi người vừa làm việc vừa tìm cách né lỗi.

Trước khi đưa phần mềm nội bộ vào dùng chung, hãy thử những công việc thật mà từng nhóm sẽ làm. Chọn tình huống bình thường, tình huống dễ sai và trường hợp cần chuyển người xử lý. Mỗi bài thử cần có kết quả mong đợi để bạn biết phần mềm đã đáp ứng hay còn vướng ở đâu.

Biến từng lo ngại thành một bài thử

Người phụ trách có thể bắt đầu bằng câu hỏi: “Điều gì sẽ khiến nhân viên không làm tiếp được?” Nếu lo người mới không biết tạo yêu cầu, bài thử là nhờ họ tạo một yêu cầu từ đầu bằng hướng dẫn hiện có. Đừng ngồi cạnh chỉ từng nút, vì như vậy bạn đang kiểm khả năng làm theo lời mình.

Viết kết quả mong đợi trước khi thử. Chẳng hạn, yêu cầu được lưu đúng nội dung, xuất hiện trong danh sách của người phụ trách và người gửi thấy trạng thái hiện tại. Nếu chỉ ghi “tạo yêu cầu thành công”, nhóm có thể bỏ qua việc người nhận chưa nhìn thấy nó.

Với nỗi lo gửi trùng, thử thao tác mà người dùng dễ làm khi chờ lâu: bấm gửi lại hoặc mở lại trang. Ghi kết quả thực tế để người phát triển xem. Không cần tự đoán nguyên nhân kỹ thuật nếu chưa có bằng chứng. Điều quan trọng là mô tả được hành động và hậu quả.

Thử dữ liệu thiếu hoặc sai theo những trường hợp có thể gặp. Nếu bỏ trống nội dung cần thiết, phần mềm có nói rõ cần bổ sung gì không? Khi nhập sai định dạng, người dùng có sửa được mà không mất phần đã điền? Thông báo lỗi nên giúp họ biết bước tiếp theo.

Quyền truy cập cần được thử bằng các tài khoản có vai trò khác nhau. Người gửi, người duyệt và người xem báo cáo không nhất thiết thấy cùng chức năng. Kiểm cả điều họ cần làm được và phần họ không được phép xem hoặc sửa theo quy định của nhóm.

Đừng dùng tài khoản quản trị cho mọi bài thử. Tài khoản đó có thể nhìn thấy chức năng mà nhân viên thường không có. Bản demo mượt với quyền cao chưa cho biết trải nghiệm của người sẽ dùng phần mềm mỗi ngày.

Nếu phần mềm thay một bảng cũ, thử cách đối chiếu các mục đã chuyển sang. Có đủ trạng thái, người phụ trách và thông tin cần thiết không? Chọn vài trường hợp đại diện để kiểm, rồi xác định phạm vi kiểm thêm. Không nên chỉ thấy tổng số mục bằng nhau là coi mọi nội dung đã đúng.

Dùng dữ liệu thử phù hợp và tách khỏi công việc đang chạy khi có thể. Nếu phải thử trên môi trường dùng thật, thống nhất rõ phạm vi và cách nhận biết bản ghi thử. Người khác không nên vô tình xử lý một yêu cầu giả như việc của khách hoặc đồng nghiệp.

Nhờ đúng người dùng thử

Nhóm phát triển thường biết đường đi trong phần mềm quá rõ. Người dùng mới lại không biết nút nào dẫn tới đâu. Vì thế, cần có người thực sự làm công việc ấy tham gia, thay vì chỉ để người tạo phần mềm tự kiểm.

Trong ví dụ, công ty mời một nhân viên ca sáng, một người ca tối và người duyệt yêu cầu. Mỗi người thử phần việc của mình. Ca tối phát hiện danh sách không cho biết yêu cầu nào đã được ca trước nhận, một chi tiết chưa xuất hiện trong buổi demo.

Cho người thử một nhiệm vụ rõ: tạo yêu cầu, tìm lại yêu cầu cũ hoặc chuyển việc khi hết ca. Quan sát chỗ họ dừng và câu hỏi họ đặt ra. Nếu ai cũng hỏi cùng một chỗ, phần hướng dẫn hoặc cách đặt tên có thể cần sửa.

Đừng vội giải thích ngay khi họ đi sai hướng. Hỏi họ đang muốn làm gì và nghĩ nút đó sẽ làm gì. Bạn sẽ hiểu vì sao giao diện gây nhầm. Sau khi ghi nhận, mới hướng dẫn để họ tiếp tục phần còn lại.

Người dùng thử không cần viết báo cáo dài. Họ có thể gửi ảnh, bước vừa làm và điều họ mong đợi. Mẫu báo lỗi bằng ảnh và mô tả rõ sẽ hữu ích nếu nhóm có nhiều người góp ý.

Kiểm trên thiết bị và cách truy cập thực tế của nhóm. Nếu nhân viên thường dùng điện thoại, đừng chỉ thử trên màn hình máy tính lớn. Nếu một số người làm ở ca khác, thử cách họ nhận việc và xem thông tin bàn giao.

Nhờ người thử phân biệt lỗi chặn công việc với điều họ muốn tiện hơn. Một nút không lưu được dữ liệu khác với việc màu nút chưa hợp mắt. Cả hai đều có thể được ghi nhận, nhưng cần mức ưu tiên khác nhau trước ngày mở dùng chung.

Cũng cần hỏi về hướng dẫn. Sau khi được giới thiệu một lần, người dùng có thể tự làm lại không? Họ biết tìm trợ giúp ở đâu khi quên bước? Một tính năng chạy đúng vẫn có thể gây khó nếu chỉ người trong nhóm phát triển biết cách sử dụng.

Có người nhận các phản hồi

Nếu góp ý nằm rải rác trong tin nhắn riêng, nhóm dễ sửa trùng hoặc bỏ sót. Chọn một nơi tiếp nhận và một người tổng hợp. Mỗi vấn đề nên có trạng thái: đã nhận, đang kiểm, cần thêm thông tin hoặc đã sửa để thử lại.

Với lỗi đã sửa, nhờ chạy lại đúng tình huống từng gây lỗi. Đừng chỉ kiểm một luồng gần giống rồi kết luận đã xong. Nếu thay đổi ảnh hưởng phần khác, kiểm thêm phần liên quan trước khi mở rộng.

Trước ngày dùng chung, chốt những vấn đề còn tồn tại. Có lỗi cần sửa trước vì người dùng không thể hoàn thành việc. Có bất tiện có thể tạm chấp nhận nếu cách xử lý rõ. Người quyết định cần biết giới hạn đang có, không chỉ nghe câu “cơ bản ổn”.

Chuẩn bị cách tiếp tục công việc nếu gặp sự cố. Nhóm sẽ ghi yêu cầu ở đâu, ai theo dõi và khi nào nhập lại? Nếu quay về cách cũ, cần tránh tạo hai nguồn dữ liệu không ai đối chiếu. Phương án dự phòng nên đủ cụ thể để dùng được khi mọi người đang bận.

Mở cho một nhóm phù hợp trước nếu hoàn cảnh cho phép. Theo dõi các câu hỏi và lỗi trong những ngày đầu, rồi điều chỉnh hướng dẫn. Một lần thử có kế hoạch sẽ cho nhiều thông tin hơn việc phát tài khoản cho tất cả rồi chờ ai gặp lỗi thì báo.

Khi mở rộng, thông báo thời điểm bắt đầu, nơi xem hướng dẫn và đầu mối hỗ trợ. Nói rõ những thay đổi trong cách làm việc, chẳng hạn nơi tạo yêu cầu mới. Người dùng cần biết mình sẽ làm gì khác từ ngày đó.

Phần mềm trong ví dụ chưa cần có mọi tính năng ngay. Nhưng trước khi cả nhóm dùng, nó cần giúp từng người hoàn thành phần việc chính và biết cách xử lý khi vướng. Buổi demo vẫn có ích; những bài thử thực tế mới cho biết phần mềm đã sẵn sàng tới mức nào.