Viết

Là một BA, khi viết 1 requirement, hãy đảm bảo viết 1 cách rõ ràng sáng sủa nhất.

Requirement rõ ràng giúp người đọc dễ hiểu đúng requirement, tránh làm sai và lãng phí nguồn lực. Bạn bất lực khi nhận ra 1 từ ngữ nào đó khiến dev team hiểu lầm, và rồi đi tong cả 1 tính năng. Việc này là 1 trong những cơn ác mộng của BA. Khi nghe brief thì dev gật gật hiểu rồi, nhưng là nói 1 đằng hiểu 1 nẻo. Dev vẫn cần document để có “giấy trắng mực đen”. Nhưng mà mặt chữ thì có khi mỗi người đọc rồi hiểu 1 kiểu. Ngữ pháp Việt Nam nó lạ lắm, sơ sẩy 1 cái là có thể lật ngược ý nghĩa lại liền. Việc viết rõ như từ điển, câu cú gãy gọn để tránh bị “lật kèo” là bí quyết sống còn.

Đỡ mất công review tới lui và xác nhận nhiều lầm. Một requirement khó hiểu sẽ dẫn đến việc hỏi đi hỏi lại, mãi không chốt được.

Những requirement mạch lạc giúp ông BA sáng dạ hơn. Khi đặt vấn đề 1 cách tường minh, những câu hỏi mấu chốt sẽ xuất hiện. Dễ dàng hiểu được bức tranh toàn cảnh và khai thác những thông tin “xịn” từ PO. Từ đó nâng cao giá trị của ông BA trong team phát triển.

Dưới đây là 3 mẹo để viết 1 requirement “rõ như ban ngày”:

Không dùng câu bị động

Khi viết requirement, hãy dùng câu khẳng định, đủ chủ ngữ vị ngữ.

Thế nào là câu bị động:

• Bài viết được lưu ở portal
• Bài viết được hiển thị lên trang chủ

Từ “được”, “bị” thể hiện câu đang dùng là câu bị động. Chúng ta có xu hướng dùng câu bị động khi thiếu thông tin, điều này rất rủi ro. Trong 2 ví dụ trên, requirement mô tả hành động nhưng thiếu đi thông tin về chủ thể thực hiện hành động. Điều này dẫn đến 2 khả năng: 1 là người đọc sẽ hỏi lại để có thêm thông tin, 2 là họ sẽ giả định theo cách hiểu của chính họ (khả năng 2 này rất chí mạng nếu người đọc giả định sai).

Thế nên 1 cấu trúc câu khẳng định sẽ đảm bảo đầy đủ ý nghĩa.

• Admin nhập liệu lưu bài viết ở portal
• Hệ thống hiển thị bài viết trên trang chủ

Bằng cách thêm vào ai hoặc cái gì thực hiện hành động, requirement đã trở nên dễ hiểu gấp 100 lần.

Không dùng tá lả thuật ngữ

1 cách nữa để khiến mớ tài liệu requirement trở thành nồi cám heo đó là: Thuật ngữ

Cùng 1 định nghĩa nhưng ông BA mỗi lúc lại gọi 1 kiểu khác nhau. Lúc thì gọi là “Admin” lúc thì gọi là “Quản trị viên”. Rồi người đọc confuse đến nỗi muốn khóc vì không chắc 2 từ đó có phải là một không.

Nếu xét 1 cách dễ tính hơn thì có thể 1 nhóm người đọc đã quen với domain bạn đang làm, có thể đọc 1 hiểu 10 thì cũng không thành vấn đề. Nhưng nếu team bạn tuyển thêm dev, mở rộng quy mô, làm tài liệu cho end-user hoặc transfer kiến thức cho 1 ông BA mới vào thay cho bạn. Mà họ lại là tấm chiếu mới trong domain đó thì sẽ bắt đầu sấp mặt. 1 vạn câu hỏi vì sao sẽ xuất hiện, đè bẹp bạn và đồng bọn.

Mỗi khi thấy xuất hiện những thuật ngữ lạ khi giao tiếp trong dự án, hãy nói lên vấn đề đó để cả team ghi nhớ và bổ sung vào Glossary.

Không dùng từ nối, câu phức

Sử dụng những câu đơn, chỉ chứa 1 mệnh đề. Không nên xào chẻ 1 câu bằng cách ghép nhiều câu nhỏ lại. Nó rất đẹp trong văn học nhưng lại rất nhức đầu khi đọc requirement.

Dấu hiệu của 1 câu phức đó là bạn sử dụng những từ như: “và”, “hoặc”, “trước khi”, “sau khi”

Ví dụ: Admin nhập liệu nhập nội dung bài viết và xem bản review trước khi lưu.

Một requirement như vầy có thể được xem là rõ ràng mạch lạc không? Trong cùng 1 câu này, sử dụng rất nhiều động từ. Tuy rằng câu được viết ở thể chủ động nhưng nó hàm chứa 3 requirement cùng 1 lúc.

• Admin nhập liệu nhập nội dung bài viết
• Admin nhập liệu xem bản review bài viết
• Admin nhập liệu lưu bài viết

Đừng viết một cách bản năng khi sử dụng quá nhiều từ nối. Hãy rạch ròi ra để nhìn thấy được cụ thể phải làm những gì. Đôi khi chỉ ba từ “trước khi lưu” mà bạn để lẫn lộn nó trong 1 câu phức tạp cũng sẽ đẻ ra một đống việc phải làm.

Thực hành

Hãy lấy ra bất cứ tài liệu requirement nào bạn đang có, do chính bạn viết hay một ai đó viết. Áp dụng 3 checklist vừa nêu bên trên để kiểm tra xem mình đang dính lỗi này nhiều như thế nào.

Sau này, mỗi khi thấy bản thân hay đồng nghiệp mắc phải thói quen tương tự thì hãy thảo luận để cùng nhau viết requirement một cách rõ ràng hơn nhé.