Khi viết brief phần mềm, nhiều đội ngũ dành rất nhiều chữ cho ý tưởng nhưng lại mô tả hời hợt phần user, role và quyền hạn. Đây là một lỗi phổ biến vì đội thi công không cần một đoạn văn hay; họ cần một mô tả đủ rõ để biết ai dùng hệ thống, ai nhìn thấy gì, ai được tạo, sửa, duyệt, xóa và ai không được làm những việc đó. Nếu phần này mơ hồ, brief nhìn có vẻ đầy đủ nhưng khi vào thi công sẽ phát sinh tranh cãi về scope, luồng duyệt, bảo mật và trách nhiệm vận hành.
Điều quan trọng không phải là viết thật dài, mà là viết đúng cấu trúc và khóa được các quyết định cần khóa. Một brief đủ điều kiện thi công phải giúp đội triển khai trả lời được bốn câu hỏi: có những nhóm người dùng nào, mục tiêu của từng nhóm là gì, mỗi nhóm được thao tác trên đối tượng nào, và giới hạn của họ nằm ở đâu.
Cấu trúc tối thiểu để mô tả user, role và quyền hạn
Bạn có thể dùng cấu trúc tối thiểu sau trong brief:
- Danh sách user type: hệ thống có những nhóm người dùng nào.
- Mục tiêu chính của từng nhóm: họ vào hệ thống để làm việc gì.
- Đối tượng họ tác động: đơn hàng, bài viết, khách hàng, báo cáo, hợp đồng, ticket, sản phẩm...
- Hành động được phép: xem, tạo, sửa, xóa, duyệt, xuất file, phân công, khóa, hoàn tiền...
- Điều kiện hoặc giới hạn: chỉ thấy dữ liệu của chính mình, chỉ duyệt trong phạm vi chi nhánh, không được xóa sau khi đã phát hành...
- Điểm cần khóa theo quyết định: quyền nào là quyết định sản phẩm, không để đội thi công tự đoán.
Chỉ cần viết đủ 6 phần trên là brief đã vượt xa mức mô tả chung chung kiểu “admin có toàn quyền, nhân viên có quyền hạn cơ bản”. Câu đó không giúp thi công vì “toàn quyền” và “cơ bản” là hai từ không thể lập trình chính xác.
Phần nào nên viết bằng tiếng đời thường
Trong giai đoạn brief, bạn nên diễn đạt bằng ngôn ngữ đời thường để tránh hiểu sai giữa founder, vận hành và đội sản phẩm. Ví dụ:
- “Nhân viên sale chỉ thấy khách hàng do mình phụ trách.”
- “Kế toán được xem đơn đã thanh toán nhưng không được sửa giá trị đơn.”
- “Quản lý chi nhánh được duyệt yêu cầu nghỉ phép của nhân viên thuộc chi nhánh mình.”
Những câu như vậy dễ kiểm tra lại với người ra quyết định, dễ phát hiện mâu thuẫn và rất phù hợp với build-commit brief vì nó bám sát hành vi thực tế.
Phần nào cần khóa theo quyết định
Có những nội dung không được để đội thi công tự suy diễn. Đây là phần cần khóa rõ trong brief:
- Phạm vi dữ liệu nhìn thấy: thấy toàn hệ thống, theo chi nhánh, theo phòng ban hay theo người phụ trách.
- Quyền duyệt: ai có quyền duyệt, duyệt một cấp hay nhiều cấp, có được duyệt đơn của chính mình không.
- Quyền sửa sau khi chốt: đơn đã xác nhận, hóa đơn đã phát hành, bài viết đã xuất bản còn được sửa không.
- Quyền xóa: xóa mềm hay xóa cứng, ai được xóa, trường hợp nào bị cấm xóa.
- Quyền xem dữ liệu nhạy cảm: doanh thu, lương, biên lợi nhuận, thông tin liên hệ khách hàng.
- Quyền thay đổi phân quyền: ai được tạo role mới, ai được gán role cho người khác.
Nếu các quyết định này chưa được chốt, brief cần ghi rõ là câu hỏi mở, không nên viết kiểu nhập nhằng để đẩy rủi ro sang giai đoạn thi công.
Mẫu mô tả ngắn nhưng đủ điều kiện thi công
Dưới đây là một mẫu rất thực dụng:
- Admin hệ thống: quản lý cấu hình hệ thống, tạo tài khoản, gán role. Xem toàn bộ dữ liệu. Không trực tiếp tham gia vận hành đơn hàng hằng ngày.
- Quản lý chi nhánh: xem dữ liệu thuộc chi nhánh mình. Duyệt đơn giảm giá dưới 20%. Không xem dữ liệu chi nhánh khác.
- Nhân viên sale: tạo và cập nhật khách hàng do mình phụ trách. Tạo báo giá và đơn hàng. Không được tự duyệt giảm giá.
- Kế toán: xem đơn đã xác nhận, cập nhật trạng thái thanh toán, xuất báo cáo công nợ. Không được sửa nội dung sản phẩm trong đơn.
Đọc mẫu trên, đội thi công có thể hình dung ngay cần có logic phân quyền theo vai trò, theo chi nhánh và theo trạng thái dữ liệu. Đó là dấu hiệu của một brief tốt.
Ví dụ xấu và ví dụ tốt
Ví dụ xấu
“Hệ thống có admin, manager và staff. Mỗi role có quyền tương ứng. Admin có tất cả quyền.”
Đoạn này gần như không thi công được vì thiếu toàn bộ thông tin thực tế: quyền trên đối tượng nào, phạm vi dữ liệu ra sao, có duyệt hay không, có giới hạn theo chi nhánh không, có sửa sau khi chốt không.
Ví dụ tốt
“Admin tạo tài khoản và cấu hình hệ thống, không tham gia xử lý đơn. Manager xem dữ liệu của chi nhánh mình, duyệt đơn giảm giá tối đa 20%, không được xem chi nhánh khác. Staff chỉ tạo và sửa đơn do mình tạo khi đơn còn ở trạng thái nháp, không được xóa đơn đã gửi duyệt.”
Đây là mô tả ngắn nhưng đã trả lời được ai làm gì, trên dữ liệu nào, trong điều kiện nào.
Checklist rà soát trước khi gửi brief sang thi công
- Bạn đã liệt kê đủ các nhóm người dùng chính chưa?
- Mỗi nhóm đã có mục tiêu sử dụng rõ ràng chưa?
- Đã nêu cụ thể đối tượng họ thao tác chưa?
- Đã chỉ ra hành động được phép và không được phép chưa?
- Đã chốt phạm vi dữ liệu họ được nhìn thấy chưa?
- Đã mô tả các quyền nhạy cảm như duyệt, xóa, xuất file, xem doanh thu chưa?
- Đã nói rõ quyền thay đổi phân quyền thuộc về ai chưa?
- Đã nêu các ngoại lệ quan trọng như “không được sửa sau khi chốt” chưa?
- Nếu còn điểm chưa quyết, brief đã đánh dấu là câu hỏi mở chưa?
Các lỗi khiến brief nghe hay nhưng không thể triển khai
- Dùng từ mơ hồ: “quyền cơ bản”, “toàn quyền”, “xem dữ liệu liên quan”.
- Trộn role với chức danh: trưởng nhóm ngoài đời không phải lúc nào cũng tương đương một role trong hệ thống.
- Không tách quyền xem và quyền sửa: nhiều hệ thống cho xem rộng nhưng sửa rất hẹp.
- Không gắn quyền với đối tượng cụ thể: nói “được quản lý” nhưng không rõ quản lý cái gì.
- Bỏ qua điều kiện trạng thái: quyền trên bản nháp khác hoàn toàn quyền trên dữ liệu đã chốt.
- Bỏ qua phạm vi dữ liệu: cùng là manager nhưng xem theo chi nhánh, khu vực hay toàn quốc tạo ra logic rất khác.
Từ hội thoại đến brief nên đi như thế nào để không thất thoát ý
Cách làm hiệu quả là đi theo ba bước. Bước một, ghi lại bằng ngôn ngữ đời thường các tình huống vận hành thực tế: ai làm việc gì, xin ai duyệt, khi nào bị từ chối. Bước hai, gom các tình huống đó thành user type, role và rule quyền hạn. Bước ba, khóa lại những quyết định ảnh hưởng đến scope như phạm vi dữ liệu, quyền duyệt và quyền sửa sau khi chốt.
Nếu làm tốt ba bước này, brief sẽ chuyển từ mức “ý tưởng để thảo luận” sang mức “đủ điều kiện thi công”. Đó cũng là tinh thần của một bản build-commit brief ở Level 3: không cố viết dài, mà viết rõ đến mức đội sản xuất có thể cam kết phạm vi, ước lượng chính xác hơn và giảm thất thoát ý giữa founder, vận hành và đội phát triển.
