Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Phần lớn nội dung hướng dẫn sử dụng đã nằm sẵn trong tài liệu đặc tả. Ba lớp chuyển đổi, ba kiểu sai AI hay mắc, và cách kiểm trước khi giao.
Còn hai ngày nữa là bàn giao. Mọi hạng mục trên bảng theo dõi đều đã có người nhận, chỉ còn dòng hướng dẫn sử dụng là chưa ai đụng tới.
Người được giao đang mở hệ thống, chụp lại từng màn hình rồi gõ lại từng bước thao tác. Trong khi đó, ngay trong thư mục dự án đã có sẵn một tài liệu đặc tả được duyệt từ mấy tháng trước, với đúng những màn hình ấy và đúng những trường ấy.
Cảnh này giống hệt chuyện làm phụ đề cho một bộ phim mà kịch bản đã ghi đủ từng câu thoại, từng cảnh, nhưng người làm phụ đề không mở kịch bản ra, lại tua phim từ đầu, nghe từng câu rồi gõ lại, vừa chậm hơn nhiều lần vừa sai nhiều hơn, bởi tai nghe không chắc bằng chữ đã viết sẵn.
Việc đang diễn ra là làm lại lần thứ hai một thứ đã làm xong, và nó lặp lại đủ nhiều để tôi coi đây là mẫu hình chứ không phải tai nạn.
Tài liệu hướng dẫn có ba đặc điểm luôn đi cùng nhau.
Việc chuyển đổi khả thi vì hai tài liệu mô tả cùng một đối tượng, chỉ khác người đọc.
Tài liệu đặc tả viết cho người xây và người nghiệm thu, nên chủ ngữ trong hầu hết các câu là hệ thống, và thứ tự trình bày đi theo cấu trúc tài liệu. Tài liệu hướng dẫn viết cho người vừa được cấp tài khoản và đang có việc phải làm xong trong hôm nay, nên chủ ngữ phải là người dùng, thứ tự đi theo trình tự thao tác, và câu nào không dẫn tới hành động đều là câu thừa.
Cần phân biệt tài liệu hướng dẫn với buổi đào tạo người dùng. Buổi đào tạo là chỗ dựng đường đi trong đầu người học nên chỉ nên đi luồng đúng, còn tài liệu là chỗ người dùng tra cứu khi đã mắc kẹt, tức là chỗ chứa những nhánh mà buổi đào tạo cố tình không dạy.
Do đó việc bạn giao cho AI là việc dịch, không phải việc sáng tác.
Ranh giới giữa những thứ AI làm được và không làm được đã có bài riêng, ở đây chỉ cần nhớ rằng phần dịch thì giao được, còn phần quyết định quy tắc nghiệp vụ thì không.
Đầu vào quyết định gần như toàn bộ chất lượng đầu ra, nên bước này đáng làm kỹ hơn cả bước viết câu lệnh.
Thứ nhất là tài liệu đặc tả đã chốt, tức bản đã khớp với hệ thống thật sau khi cấu hình và lập trình xong, chứ không phải bản được duyệt hồi đầu dự án. Đưa bản cũ vào thì bạn nhận về một bộ hướng dẫn mô tả một hệ thống không tồn tại, mà nó vẫn đọc trơn tru nên không ai phát hiện, cho tới khi người dùng làm theo và không thấy nút đâu.
Thứ hai là ảnh chụp màn hình của hệ thống thật, đã cấu hình đúng, đã Việt hóa, và đã đánh số các thành phần khớp với thứ tự dòng trong bảng mô tả trường.
Chất lượng của bảng trường và bộ ảnh đánh số quyết định năng suất ở bước này, còn cách làm bảng đó tôi đã viết ở bài về bảng GUI element. Ngoài ra, những ảnh này thường được chụp trên môi trường dựng thử với dữ liệu thật của khách, nên việc làm sạch tài liệu trước khi đưa cho AI, chủ đề của bài trước, là việc bạn bắt buộc phải xử lý xong trước.
Thứ ba là danh sách vai người dùng, tức ai đọc phần nào, kèm một bản mẫu để công cụ khỏi tự chọn bố cục. Một bộ gộp mọi vai vào một file là bộ không ai đọc, bởi nhân viên kho phải lật qua ba mươi trang của phòng kinh doanh mới tới được phần của mình.
Cách chia mà tôi thấy dùng được là tách thành ba lớp rồi xử lý lần lượt từng lớp.
Lớp thứ nhất là đổi chủ ngữ. Một dòng trong tài liệu đặc tả ghi rằng hệ thống cho phép ghi nhận số dư trả trước trên hồ sơ đại lý, còn dòng tương ứng trong hướng dẫn phải là một câu mệnh lệnh bắt đầu bằng động từ và kết thúc bằng thứ người dùng nhìn thấy trên màn hình.
Quy tắc đáng áp cho lớp này là mỗi câu chỉ chứa một thao tác, bởi người đang mắc kẹt dò từng dòng chứ không đọc hiểu cả đoạn, nên hai thao tác gói trong một câu là chỗ họ sẽ bỏ sót mất một cái.
Lớp thứ hai là đổi độ mịn. Ba loại luồng trong tài liệu đặc tả được viết ở mức nghiệp vụ, và cách phân định chúng đã có bài riêng, nhưng mức đó chưa đủ mịn để làm theo: luồng chính ghi rằng người bán tạo đơn rồi xác nhận, còn người dùng cần biết vào menu nào, bấm nút nào, và sau khi xác nhận thì trạng thái đổi thành gì.
Về cách sắp xếp, luồng chính trở thành phần thân của mục hướng dẫn, luồng thay thế thành một mục ngắn kiểu cách làm khác cho cùng kết quả, còn luồng ngoại lệ thì nên gom về cuối mỗi tính năng. Lý do là người dùng chỉ tìm tới phần đó khi đã bị chặn, và lúc ấy thứ họ cần là một danh sách để dò xem mình đang rơi vào tình huống nào.
Lớp thứ ba hay bị bỏ nhất, và chính nó tạo ra khác biệt giữa một bộ hướng dẫn dùng được với một bộ chỉ để nộp cho đủ.
Quy tắc nghiệp vụ trong tài liệu đặc tả được viết dưới dạng ràng buộc của hệ thống, còn trong hướng dẫn thì phải viết lại thành thứ người dùng nhìn thấy cộng với việc họ phải làm tiếp. Quy tắc rằng chỉ trưởng phòng kinh doanh được sửa hạn mức công nợ, khi sang hướng dẫn, trở thành một câu đặt dưới ảnh, rằng nếu bạn không thấy ô này thì do vai của bạn không được sửa, kèm tên người cần liên hệ. Thiếu câu đó thì người dùng nghĩ hệ thống bị lỗi, và bạn nhận thêm một dòng vướng mắc trong tuần đầu sau go-live.
Đặc biệt cần chú ý nhóm quy tắc về trường bắt buộc và giá trị mặc định, vì đây là chỗ tài liệu hay ghi nửa chừng. Tài liệu ghi rằng kho xuất mặc định không bắt buộc chọn, nhưng không ghi để trống thì hệ thống lấy kho nào, mà đó lại đúng là câu người dùng cần được trả lời. Gặp một chỗ như vậy thì việc phải làm không phải là bảo công cụ đoán, mà là quay lại hỏi khách rồi bổ sung vào cả hai tài liệu.
Hãy làm từng màn hình một, trong thư mục làm việc đã được dựng sạch theo cách ở bài trước.
Lý do không phải vì công cụ không tải nổi, mà vì bạn không kiểm nổi. Một bản nháp vài chục trang thì bạn sẽ đọc lướt, và đọc lướt một văn bản trơn tru chính là cách sai sót lọt qua.
Ba ràng buộc chung khi làm tài liệu bằng AI đã có bài riêng nói đủ, còn ràng buộc thứ tư thì riêng cho việc viết hướng dẫn: chỉ dùng thông tin có trong tài liệu và bộ ảnh, chỗ nào thiếu thì để lại một nhãn cố định thay vì tự viết cho liền mạch.
Đếm số nhãn đó là cách rẻ nhất mà tôi biết để đo chất lượng tài liệu đặc tả: vài nhãn trên một màn hình thì bình thường, còn hàng chục nhãn nghĩa là tính năng đó chưa đủ để bàn giao.
Ba kiểu dưới đây là những gì tôi lường trước từ cách công cụ suy ra nội dung, chứ chưa phải thống kê lỗi trên một tập bản nháp đủ lớn.
Kiểu thứ nhất là bịa nút. Tài liệu đặc tả mô tả trạng thái chứ ít khi mô tả nút, nên khi tài liệu ghi rằng chứng từ chuyển sang chờ duyệt, công cụ suy ra phải có một nút tên Duyệt rồi viết luôn bước bấm nút đó, trong khi việc chuyển trạng thái có thể là tự động. Cách bắt là đối chiếu từng câu mệnh lệnh với ảnh, và mọi tên nút không có trong ảnh đều bị coi là chưa xác minh.
Kiểu thứ hai là nhầm thứ tự bước. Thứ tự dòng trong bảng trường là thứ tự thiết kế dữ liệu chứ không phải thứ tự nhập liệu, nên bản nháp hay bảo người dùng điền một trường chỉ hiện ra sau khi đã chọn xong một trường khác. Cách bắt là đi lại đúng thứ tự đó trên hệ thống, và đây là loại lỗi đọc thì không thấy, còn làm thì thấy ngay.
Kiểu thứ ba là viết chung chung ở đúng những chỗ tài liệu gốc thiếu, chẳng hạn điền các thông tin cần thiết, hoặc hệ thống sẽ xử lý tương ứng. Đây là kiểu nguy hiểm nhất, vì nó lấp đúng cái lỗ hổng lẽ ra phải lộ ra. Cách bắt là dựng sẵn một danh sách các cụm mơ hồ rồi tìm chúng trong bản nháp, mỗi lần gặp thì thay bằng nội dung cụ thể, hoặc thừa nhận rằng tài liệu gốc thiếu chỗ này.
Công cụ AI chuyển được ngôn ngữ và chuyển được cấu trúc, nhưng nó không chuyển được thứ mà tài liệu gốc không có.
Nếu tài liệu đặc tả thiếu một bước phê duyệt, một điều kiện rẽ nhánh, hay lời giải thích một trường dùng để làm gì, thì bộ hướng dẫn cũng thiếu đúng chỗ ấy. Khác biệt duy nhất, và là khác biệt nguy hiểm, nằm ở chỗ bản viết tay thiếu một cách lộ liễu bằng khoảng trống hoặc câu cụt, còn bản sinh ra thì thiếu một cách trơn tru: đoạn văn vẫn đủ ba bước, vẫn đúng giọng, và không có dấu hiệu nào cho người review bám vào.
Do đó cách duy nhất để bắt nhóm thiếu sót này là làm theo hướng dẫn trên hệ thống thật, chứ không phải đọc lại hướng dẫn.
Trong trường hợp dự án không có tài liệu đặc tả tử tế để chuyển đổi thì đừng dùng cách trong bài này. Chuyện đó xảy ra thường hơn nhiều người tưởng, và tôi từng gặp dự án ký xong vài ngày là bắt đầu chạy, bốn mươi lăm ngày sau đã go-live. Lúc đó bạn phải đi ngược lại:
Cách này chậm hơn, nhưng trung thực với hệ thống thật.
Bản nháp trả về không phải bản giao, và bước kiểm lại không được rút gọn kể cả khi chỉ còn hai ngày, bởi một bộ hướng dẫn sai còn tốn hơn không có hướng dẫn: người dùng làm theo, ra kết quả sai, rồi bạn đi sửa cả hai.
Checklist kiểm lại mà tôi dùng gồm:
Việc cuối cùng đáng giá nhất và cũng hay bị bỏ nhất. Người đã đọc tài liệu đặc tả thì tự lấp khoảng trống mà không nhận ra mình đang lấp, còn người chưa biết gì thì dừng đúng chỗ hướng dẫn thiếu, và mỗi lần họ dừng là một dòng bạn phải sửa.
Cần lưu ý rằng cách làm này không biến việc viết hướng dẫn thành việc nhàn. Tôi không đưa ra con số tiết kiệm được bao nhiêu vì tôi chưa đo, và bộ hướng dẫn mẫu tôi vẫn dùng thì tới giờ vẫn là hàng viết tay. Thứ đổi được ở đây là đổi phần việc gõ lại lấy phần việc kiểm lại, và đó là cuộc đổi chỉ có lợi khi tài liệu đặc tả của bạn đủ tốt ngay từ đầu.
Nhìn rộng ra thì đây chỉ là một mắt trong chuỗi dài những chỗ mà công sức bỏ ra ở giai đoạn trước quyết định cái giá phải trả ở giai đoạn sau. Khi cả chuỗi đó bị bỏ qua thì dự án không hỏng ở một điểm mà hỏng dần ở nhiều điểm, và chữ thất bại trong các dự án ERP thực ra nghĩa là gì thì đáng nói riêng một bài.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận