Buổi xem bản thử (demo) định kỳ là lúc rẻ nhất để phát hiện một yêu cầu bị hiểu sai: màn hình mới làm vài ngày, sửa còn nhẹ. Khách bỏ qua các buổi đó thì mọi khác biệt dồn lại tới buổi nghiệm thu, khi phần mềm đã hoàn chỉnh và sửa một luồng có thể kéo theo cả chục màn hình. Nhịp hợp lý là mỗi đợt làm việc một buổi, người xem là người sẽ dùng thật, và phản hồi được ghi vào danh sách chung ngay trong buổi.
Vì sao hiểu sai là không tránh được
Dù trang yêu cầu và đặc tả viết kỹ, chữ vẫn có nhiều cách hiểu. "Báo cáo doanh số theo tuần" là tuần từ thứ Hai hay từ Chủ nhật, tính theo ngày tạo đơn hay ngày giao hàng. Người viết mã chọn một cách hợp lý; người dùng thật có thể quen cách kia. Không ai sai, và chỉ nhìn thấy màn hình mới lộ ra khác biệt.
Chi phí sửa tăng theo thời gian một khác biệt tồn tại. Phát hiện ở bản thử tuần đầu, sửa một màn hình. Phát hiện lúc nghiệm thu, có thể phải sửa cả báo cáo, dữ liệu mẫu, tài liệu hướng dẫn và các màn hình khác dựa trên cách hiểu cũ.
Nhịp xem bản thử
Ở ALODEV, dự án làm theo đợt 2 tuần, cuối mỗi đợt có bản chạy thử và buổi rà soát chung; danh sách việc và lỗi dùng chung với người phụ trách phía doanh nghiệp (trang Quy trình). Với nhà cung cấp khác, hãy đòi nhịp tương tự ghi trong hợp đồng: bao lâu một lần có bản thử, xem ở đâu, ai tham dự. Nhịp dài hơn một tháng là quá thưa cho phần mềm doanh nghiệp.
Chuẩn bị buổi demo ba mươi phút
| Phút | Việc | Ai làm |
|---|---|---|
| 0 đến 5 | Nhắc lại phạm vi đợt này: làm xong gì, chưa làm gì | Bên làm |
| 5 đến 20 | Người dùng thật tự bấm các luồng chính, bên làm chỉ quan sát | Bên mua |
| 20 đến 27 | Ghi từng phản hồi vào danh sách chung, phân loại lỗi hay yêu cầu mới | Hai bên |
| 27 đến 30 | Chốt việc đợt sau và việc bên mua cần trả lời | Hai bên |
Điểm quan trọng nhất là phút 5 đến 20: người dùng thật tự bấm. Khi bên làm bấm, mọi thứ trông trơn tru vì họ biết đường đi. Khi nhân viên kho hay kế toán tự bấm, họ sẽ đi đúng những đường bên làm không nghĩ tới.
Bấm thử những gì
- Luồng việc hằng ngày với dữ liệu gần thật, không phải dữ liệu mẫu ba dòng.
- Trường hợp biên: đơn đúng bằng ngưỡng duyệt, ngày cuối tháng, khách không có số điện thoại.
- Thao tác sai: nhập chữ vào ô số, bấm lưu hai lần, quay lại giữa chừng.
- Quyền: đăng nhập bằng vai trò thấp nhất và thử mở màn hình không được phép.
- Trên thiết bị người dùng sẽ dùng thật: điện thoại của nhân viên bán hàng, máy tính cũ ở kho.
Ghi phản hồi để không trôi mất
Phản hồi nói miệng trong buổi demo thường biến mất sau một tuần. Mỗi phản hồi cần một dòng trong danh sách chung, gồm: màn hình nào, làm gì, thấy gì, mong đợi gì, và phân loại. Phân loại quan trọng vì nó quyết định tiền: lỗi (phần mềm làm khác đặc tả đã duyệt) thì bên làm sửa trong phạm vi; yêu cầu mới (đặc tả không có) thì đi theo quy trình thay đổi yêu cầu, có ước lượng và duyệt.
| Màn hình | Thấy | Mong đợi | Loại |
|---|---|---|---|
| Tạo đơn | Đơn 50.000.000 đồng tự chuyển kho | Đơn từ 50 triệu phải chờ duyệt (CN-07) | Lỗi |
| Báo cáo tuần | Tuần tính từ Chủ nhật | Tuần tính từ thứ Hai | Cần làm rõ đặc tả |
| Danh sách khách | Không lọc được theo tỉnh | Lọc theo tỉnh | Yêu cầu mới |
Dấu hiệu buổi demo đang bị dựng
- Bên làm luôn là người bấm, người dùng không được chạm vào.
- Dữ liệu trên màn hình giống hệt nhau giữa các buổi.
- Một số nút bị né: "phần này đang làm, bấm vào sẽ lỗi".
- Không có đường dẫn để người dùng tự vào thử giữa hai buổi.
- Buổi demo bị dời liên tục mà không có lý do cụ thể.
Bản thử thật có đường dẫn riêng, người dùng vào được bất cứ lúc nào, và bản mới được cập nhật tự động sau mỗi lần đội làm hoàn thành một phần. Bài CI/CD với GitHub Actions trên blog Trần Công Thắng giải thích cơ chế tự động đưa bản mới lên môi trường thử, lý do một bản thử có thể mới mỗi ngày mà không tốn công.
Sau buổi demo: ai làm gì trong tuần
Bên làm xử lý các dòng loại lỗi, trả lời các dòng cần làm rõ đặc tả, và gửi ước lượng cho các dòng yêu cầu mới. Bên mua trả lời câu hỏi nghiệp vụ trong thời hạn thoả thuận và quyết duyệt hay không duyệt các yêu cầu mới trước buổi sau. Hai bên cùng nhìn một danh sách, nên buổi demo sau bắt đầu bằng việc xem các dòng của buổi trước đã đóng chưa.
Nếu hai buổi liên tiếp vẫn còn nhiều dòng của buổi trước chưa đóng, đó là tín hiệu tiến độ đang chậm hơn báo cáo. Nêu ngay trong buổi, trước khi xem phần mới.
Khi phía doanh nghiệp là người chậm
Buổi demo cũng lộ ra chậm trễ ở phía người mua: câu hỏi nghiệp vụ gửi từ buổi trước chưa ai trả lời, dữ liệu mẫu hứa gửi chưa gửi, người dùng được mời nhưng không đến. Mỗi việc như vậy đẩy lùi phần làm của đợt sau. Ghi các việc của bên mua vào cùng danh sách với các việc của bên làm, có người nhận và hạn, và mở chúng ra đầu buổi như mọi dòng khác. Hai bên nhìn thấy cùng một bức tranh thì không ai phải đoán vì sao lịch trượt, và khi cần điều chỉnh mốc nghiệm thu, hai bên có sẵn bằng chứng để thống nhất.
Câu hỏi thường gặp
Demo phần mềm là gì?
Là buổi trình diễn phần mềm đang làm cho khách xem và dùng thử. Trong dự án làm riêng, demo định kỳ là cách kiểm tiến độ và phát hiện hiểu sai sớm.
Bao lâu nên xem bản thử một lần?
Mỗi đợt làm việc một lần, thường một đến hai tuần. Thưa hơn một tháng thì khác biệt tích luỹ quá nhiều.
Ai phía doanh nghiệp nên dự buổi demo?
Người phụ trách dự án và ít nhất một người sẽ dùng phần mềm hằng ngày. Giám đốc dự các buổi quan trọng là đủ.
Phản hồi trong demo có tính là yêu cầu thay đổi không?
Chỉ khi nó nằm ngoài đặc tả đã duyệt. Phần mềm làm khác đặc tả là lỗi, bên làm sửa trong phạm vi.
Bên làm không cho xem bản thử thì sao?
Đó là dấu hiệu rủi ro lớn. Hợp đồng nên ghi nhịp bản thử, và thanh toán nên gắn với bản chạy thử nhìn thấy được.
