Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Công thức viết exception flow không sót: mỗi business rule sinh ra ít nhất một nhánh ngoại lệ. Và vì sao chọn main flow là một quyết định thiết kế.
Buổi kiểm thử với người dùng, một nhân viên kho bấm nút xác nhận hai lần liên tiếp vì lần đầu màn hình hơi chậm, và tới cuối buổi thì trong danh sách issue có một dòng ghi rằng hệ thống tạo ra hai chứng từ cho cùng một đơn hàng. Không ai trong đội triển khai nghĩ tới tình huống đó, và trong tài liệu đặc tả của tính năng này, mục luồng ngoại lệ ghi đúng một dòng, rằng nếu thiếu thông tin bắt buộc thì hệ thống báo lỗi.
Đây là mục bị viết qua loa nhất trong mọi tài liệu đặc tả mà tôi từng đọc, kể cả những tài liệu được đầu tư rất kỹ ở các phần khác, và nguyên nhân thì dễ hiểu: luồng chính có sẵn trong đầu bạn sau buổi khảo sát, còn luồng ngoại lệ thì phải ngồi nghĩ ra, mà nghĩ ra thì luôn có cảm giác là còn thiếu.
Bài này nói về cách để không phải ngồi nghĩ, và cách đó bắt đầu bằng việc phân định lại ba loại luồng, bởi ranh giới giữa chúng bị viết nhầm khá thường xuyên.
Chỗ hay nhầm nằm giữa luồng thay thế và luồng ngoại lệ, và tiêu chí phân biệt rất gọn, đó là nhìn vào kết quả cuối. Nếu người dùng vẫn đạt được kết quả mong muốn và chỉ là đi bằng đường khác thì đó là luồng thay thế; còn nếu người dùng không đạt được kết quả, tức bị chặn, bị cảnh báo, không lưu được, hoặc lưu được nhưng sang một trạng thái khác, thì đó là luồng ngoại lệ.
Lấy tính năng tạo đơn bán hàng làm ví dụ. Tạo đơn từ menu đơn hàng và tạo đơn xuất phát từ một cơ hội trong phân hệ CRM đều dẫn tới cùng một loại chứng từ, nên cái thứ hai là luồng thay thế; còn tạo đơn cho một khách đang có công nợ vượt hạn mức và bị hệ thống chặn lại thì đó là luồng ngoại lệ, dù thao tác của người dùng gần như y hệt.
Cần lưu ý rằng một luồng ngoại lệ không nhất thiết kết thúc bằng thất bại. Rất nhiều ngoại lệ kết thúc bằng việc chuyển sang một luồng khác, chẳng hạn đơn vượt hạn mức thì không bị hủy mà chuyển sang trạng thái chờ duyệt, và điều đó vẫn là ngoại lệ bởi kết quả khác với kết quả của luồng chính.
Đây là luận điểm mà tôi thấy ít được nói ra, và nó thay đổi cách bạn viết cả mục này.
Trên một nền tảng như Odoo, cùng một đối tượng thường tạo được ở nhiều chỗ khác nhau. Do đó khi bạn viết rằng luồng chính là vào menu này rồi bấm nút kia, bạn không mô tả một sự thật của hệ thống mà đang đưa ra một lựa chọn về cách người dùng nên đi.
Lấy một ví dụ cụ thể. Giả sử khách cần quản lý danh sách cửa hàng của từng đại lý, và bạn có hai hướng thiết kế.
Hướng thứ nhất là thêm một tab ngay trong màn hình thông tin liên hệ của đại lý, và người dùng vào đại lý rồi mở tab đó để thêm cửa hàng; với thiết kế này thì luồng vào liên hệ rồi vào tab là luồng chính, còn luồng vào menu danh sách cửa hàng để tạo rồi gắn ngược lên đại lý là luồng thay thế. Hướng còn lại là để danh sách cửa hàng thành một menu riêng và đặt một nút tắt trong màn hình liên hệ để nhảy sang, và khi đó mọi thứ đảo lại: vào thẳng menu cửa hàng để tạo mới là luồng chính, còn đi qua nút tắt trong màn hình liên hệ là luồng thay thế.
Hệ thống chấp nhận cả hai cách trong cả hai thiết kế. Cái khác nhau là bạn muốn điều hướng người dùng đi đường nào, và cái quyết định đó lan ra rất xa, bởi tài liệu hướng dẫn sử dụng viết theo luồng chính, buổi đào tạo dạy theo luồng chính, kịch bản kiểm thử chạy theo luồng chính, và sau một thời gian thì thói quen của người dùng cũng đi theo luồng chính, tới mức nếu bạn muốn đổi thì phải đào tạo lại chứ không chỉ sửa tài liệu.
Vì vậy trước khi viết mục này, hãy hỏi lại chính mình rằng luồng bạn chọn có phải là luồng ít thao tác nhất cho người làm việc đó nhiều nhất hay không. Nếu người nhập liệu chính là nhân viên kho mà luồng chính lại bắt họ đi qua ba màn hình của bộ phận kinh doanh thì thiết kế đang phục vụ sơ đồ dữ liệu chứ không phục vụ người dùng.
Cách để không phải ngồi nghĩ xem còn thiếu trường hợp nào là đừng bắt đầu từ trường hợp, mà bắt đầu từ quy tắc nghiệp vụ.
Nguyên tắc rất gọn: mỗi quy tắc nghiệp vụ sinh ra ít nhất một nhánh ngoại lệ.
Quy tắc là câu khẳng định về cái được phép, còn ngoại lệ là chuyện gì xảy ra khi cái đó không thỏa, do đó nếu bạn liệt kê được hết quy tắc thì bạn có sẵn danh sách ngoại lệ mà không cần sáng tạo gì thêm.
Bốn bước, làm tuần tự:
Bước hai là bước quyết định, và nó cụ thể hơn nghe qua. Giả sử ba quy tắc của doanh nghiệp là đơn trên một mức tiền nhất định phải qua duyệt của trưởng phòng, khách đang có công nợ quá hạn thì không được đặt đơn mới, và hàng thuộc nhóm kiểm soát chất lượng thì phải có phiếu kiểm trước khi nhập kho. Lật ngược quy tắc thứ nhất được một nhánh, là người tạo cố xác nhận thẳng đơn vượt mức. Lật ngược quy tắc thứ hai được hai nhánh, một là khách đã quá hạn mà vẫn tạo đơn, hai là đơn đã tạo xong rồi mới phát sinh quá hạn, và nhánh thứ hai này kéo theo câu hỏi ai được phép cho qua. Lật ngược quy tắc thứ ba được một nhánh, là phiếu kiểm kết luận không đạt thì hàng đi đâu. Chỉ với ba quy tắc, bạn đã có bốn nhánh, và cả bốn đều là nhánh có thật chứ không phải nhánh tưởng tượng.
Bước ba, tức việc gom nhóm theo thời điểm hệ thống chặn, là cách phân loại theo kinh nghiệm của tôi, chứ không phải một chuẩn có sẵn, và lý do dùng nó rất thực dụng: đội phát triển cần biết chỗ nào kiểm tra ở tầng giao diện, chỗ nào ràng buộc ở tầng dữ liệu, và với mỗi chỗ thì thông báo hiện ra như thế nào.
Bước bốn thì chính là áp dụng nguyên tắc kế thừa mặc định mà bạn đã ghi ở đầu tài liệu đặc tả, nên tôi không nhắc lại ở đây; chỉ giữ những nhánh phát sinh từ quy tắc của chính doanh nghiệp này.
Bốn bước trên biến một việc dựa vào trí nhớ thành một việc cơ học, và cái được lớn nhất không phải là viết nhanh hơn mà là bạn biết mình đã dừng ở đâu và vì sao dừng ở đó.
Công thức trên chỉ tốt bằng danh sách quy tắc mà bạn có, nên câu hỏi tiếp theo là lấy quy tắc ở đâu cho đủ.
Trước hết phải nhớ rằng quy tắc nghiệp vụ do doanh nghiệp cung cấp chứ không do bạn nghĩ ra. Nghe hiển nhiên, nhưng trong thực tế rất nhiều dòng trong mục này là suy đoán của người viết tài liệu, và suy đoán đó tới giai đoạn kiểm thử mới bị phát hiện là sai.
Khó khăn nằm ở chỗ quy tắc thường không được nói ra trong buổi khảo sát, bởi với người trong cuộc thì nó hiển nhiên tới mức không đáng nhắc. Không ai tự nhiên nói rằng khách nợ quá hạn thì không bán tiếp; họ chỉ nói rằng khi có đơn thì kế toán sẽ kiểm tra công nợ, và bạn phải hỏi tiếp rằng kiểm tra xong thì thế nào, quá hạn bao nhiêu ngày thì dừng, và ai được phép cho qua.
Ngoài ra còn một tình huống nữa hay gặp, là một phần quy tắc chưa được doanh nghiệp thống nhất nội bộ tại thời điểm bạn hỏi. Khi gặp tình huống đó thì đừng ngồi chờ họ tranh luận tới khi ra kết quả, hãy ghi lại vào danh sách chờ và đề nghị họ chốt nội bộ rồi gửi lại sau buổi khảo sát, để buổi làm việc còn chạy tiếp được.
Đồng thời có một chỗ đáng để mắt tới khi bạn xin biểu mẫu và báo cáo của doanh nghiệp, đó là những ô được tô màu hoặc ghi chú bằng tay trên file Excel họ đang dùng. Những chỗ đó thường là nơi một quy tắc đang được thực thi bằng con người, và mỗi chỗ như vậy là một quy tắc chưa được ai nói ra.
Nội dung đã đủ thì còn chuyện hình thức, và hình thức ở đây có tác động thực tế chứ không phải chuyện trình bày.
Đánh số từng bước, mỗi bước một hành động, và mỗi hành động phải có chủ ngữ rõ ràng là người dùng hay hệ thống. Câu kiểu đơn hàng được xác nhận là câu không nói ai xác nhận, và đội phát triển đọc câu đó sẽ tự quyết định.
Ở mỗi bước có rẽ nhánh thì ghi thẳng điều kiện và ghi số của luồng sẽ nhảy tới, chứ không viết chung chung rằng nếu không thỏa thì xử lý theo luồng ngoại lệ. Một tài liệu tốt là tài liệu mà người kiểm thử đọc xong đếm được có bao nhiêu trường hợp cần kiểm.
Với mỗi luồng ngoại lệ thì ghi ba thứ, gồm:
Thiếu thứ ba là chỗ hay bị bỏ nhất, và nó là chỗ sinh ra dữ liệu rác, bởi khi tài liệu không nói rõ thì đội phát triển thường chọn cách dễ nhất là để nguyên bản ghi ở trạng thái dở dang.
Cuối cùng, hãy viết thông báo lỗi bằng đúng câu chữ mà bạn muốn người dùng nhìn thấy. Nếu bạn để đội phát triển tự nghĩ thì kết quả thường là một câu mô tả nguyên nhân kỹ thuật, còn người dùng thì cần biết họ phải làm gì tiếp theo.
Dù bạn có cắt tài liệu tới đâu thì bốn mục vừa nói và ba luồng cộng quy tắc nghiệp vụ luôn vẫn phải giữ, và lý do không nằm ở quy định mà nằm ở tuổi thọ.
Giao diện sẽ đổi qua các phiên bản, tên trường có thể đổi khi phần cấu hình được chuyển sang lập trình, còn quy tắc nghiệp vụ của doanh nghiệp thì gần như giữ nguyên; do đó khi có người hỏi tại sao hệ thống chặn ở chỗ này, đó là bốn mục duy nhất trả lời được, và cũng là bốn mục mà một đối tác triển khai tiếp theo cần đọc nhất.
Phần còn lại của một mục đặc tả là ảnh chụp màn hình và bảng mô tả các thành phần giao diện, và đó là phần trông giống việc vặt nhất trong cả tài liệu nhưng lại quyết định năng suất của mọi việc bạn làm sau khi go-live.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận