Trước khi viết một dòng code, đội dự án cần trả lời rất rõ một câu hỏi rất đời thường: ai sẽ dùng hệ thống, họ được làm gì, không được làm gì và khi có tranh cãi thì ai là người chốt cuối cùng. Đó chính là phần cốt lõi của việc chốt user role và quyền hạn trước khi thi công.
Nhiều dự án tưởng như đã sẵn sàng vì ai cũng nói được ý tưởng lớn. Nhưng đến lúc build mới lộ ra hàng loạt câu hỏi: nhân viên có được sửa đơn đã duyệt không, quản lý có xem dữ liệu của mọi chi nhánh không, kế toán được hủy giao dịch hay chỉ được đối soát, founder có muốn hệ thống linh hoạt hay kiểm soát chặt. Những câu hỏi này không phải chi tiết nhỏ. Đây là phần quyết định sản phẩm sẽ chạy mượt hay liên tục phải sửa giữa đường.
Ba mức hiểu bài toán phần mềm
Có thể hình dung việc làm rõ bài toán theo ba mức:
- Mức 1 - biết ý tưởng: biết sản phẩm để làm gì, phục vụ ai, có vài màn hình chính.
- Mức 2 - biết luồng chính: mô tả được các bước sử dụng cơ bản, ai thao tác ở bước nào, dữ liệu đi từ đâu đến đâu.
- Mức 3 - đủ điều kiện thi công: chốt rõ role, quyền hạn, điều kiện ngoại lệ, scope in scope out, trade-off sản phẩm và cơ chế ra quyết định trước khi build.
Nhiều dự án dừng ở mức 1 hoặc mức 2 vì mọi người thường lầm tưởng rằng nói rõ mục tiêu kinh doanh là đã đủ. Thực tế, sản phẩm chỉ thật sự rõ khi đội dự án thống nhất được những quyết định vận hành hằng ngày. Ví dụ: ai được tạo dữ liệu, ai được duyệt, ai được sửa sau duyệt, ai chỉ được xem, quyền nào áp dụng toàn hệ thống, quyền nào chỉ áp dụng trong phạm vi chi nhánh hoặc nhóm.
Trong cách làm của AI Tạo Phần Mềm, đây là lúc dự án cần được kéo lên Level 3: không chỉ hiểu mong muốn, mà phải chuyển mong muốn thành mô tả có thể build được.
Vì sao nhiều dự án không lên được Level 3
- Sợ mất thời gian: founder muốn làm nhanh nên chọn cách "cứ build trước rồi sửa sau".
- Tránh quyết định khó: mỗi quyền hạn đều kéo theo đánh đổi giữa linh hoạt và kiểm soát.
- Thiếu người chốt cuối: nhiều bên cùng góp ý nhưng không ai có quyền quyết định.
- Không tách được scope: cái gì cũng thấy cần, dẫn đến phạm vi mơ hồ.
Kết quả là đội phát triển phải tự đoán. Mà khi dev phải đoán, sản phẩm gần như chắc chắn sẽ lệch kỳ vọng ở một điểm nào đó.
Bước đi thực tế để kéo dự án lên mức đủ rõ trước khi thi công
1. Chốt danh sách role thật ngắn gọn
Đừng bắt đầu bằng một ma trận quyền dài hàng trăm dòng. Hãy bắt đầu bằng câu hỏi: hệ thống này thật sự có bao nhiêu vai trò người dùng khác nhau về mặt trách nhiệm?
Một cách làm thực tế là liệt kê theo kết quả công việc, không theo chức danh nội bộ. Ví dụ:
- Người tạo dữ liệu
- Người kiểm tra hoặc duyệt
- Người quản trị cấu hình
- Người chỉ xem báo cáo
- Người xử lý ngoại lệ
Nếu hai nhóm có hành vi gần giống nhau, hãy gộp lại. Chỉ tách role khi sự khác nhau về quyền thật sự tạo ra khác biệt trong luồng xử lý.
2. Chốt quyền theo hành động, không theo cảm giác
Với mỗi role, cần trả lời rõ các hành động chính:
- Được tạo gì
- Được xem gì
- Được sửa gì
- Được xóa gì
- Được duyệt hay từ chối gì
- Được xem dữ liệu trong phạm vi nào
- Được can thiệp sau khi một bước đã hoàn tất hay không
Đây là lúc nhiều xung đột lộ ra. Ví dụ founder muốn nhân viên thao tác nhanh, nhưng quản lý lại muốn mọi thay đổi đều qua phê duyệt. Không có phương án nào đúng tuyệt đối. Đây là bài toán trade-off sản phẩm. Muốn nhanh thì phải chấp nhận rủi ro. Muốn kiểm soát chặt thì phải chấp nhận thêm bước vận hành.
3. Chốt các tình huống ngoại lệ trước khi build
Phần lớn lỗi phát sinh không nằm ở luồng đẹp, mà ở ngoại lệ. Ví dụ:
- Đơn đã duyệt nhưng cần sửa gấp thì ai được mở khóa
- Người nghỉ việc thì dữ liệu bàn giao thế nào
- Một người có nhiều vai trò thì ưu tiên quyền nào
- Chi nhánh A có được xem dữ liệu chi nhánh B không
- Khi mất mạng hoặc nhập sai thì hệ thống cho rollback tới đâu
Nếu chưa trả lời được các câu hỏi này, nghĩa là bài toán chưa sẵn sàng để thi công.
4. Chốt scope in scope out
Không thể chốt role và quyền hạn nếu chưa chốt phạm vi. Một số quyền chỉ cần vì đội dự án đang vô thức ôm quá nhiều chức năng vào phiên bản đầu.
Vì vậy cần viết thẳng ra:
- Scope in: những quyền và luồng bắt buộc phải có ở phiên bản này.
- Scope out: những quyền và luồng biết là cần nhưng chưa làm ở giai đoạn hiện tại.
Khi viết rõ scope in scope out, cuộc họp sẽ bớt tranh cãi cảm tính và dễ chốt hơn rất nhiều.
5. Chỉ định người có quyền quyết định
Mỗi dự án cần một cơ chế ra quyết định rõ ràng. Nếu không, cùng một câu hỏi sẽ được hỏi lại nhiều lần và mỗi lần lại có một câu trả lời khác.
Tối thiểu nên chốt:
- Ai quyết định về nghiệp vụ
- Ai quyết định về trải nghiệm người dùng
- Ai quyết định khi có xung đột giữa tốc độ và kiểm soát
- Ai là người duyệt bản mô tả cuối trước khi build
Đây là điểm rất quan trọng của Decision Freeze: đến một thời điểm nhất định, các quyết định cốt lõi phải được đóng băng tương đối để đội phát triển có thể thi công ổn định. Không có Decision Freeze, dự án sẽ luôn ở trạng thái nửa làm nửa đổi.
Cần chốt gì trước khi build
Trước khi chuyển sang thi công, nên có một bản build-commit brief ngắn gọn nhưng rõ ràng. Tài liệu này không cần dài, nhưng phải đủ để cả business, product và tech cùng hiểu giống nhau.
Một build-commit brief tối thiểu nên có:
- Mục tiêu của phiên bản này
- Danh sách role đã chốt
- Quyền chính của từng role
- Các ngoại lệ bắt buộc xử lý
- Scope in scope out
- Trade-off đã chấp nhận
- Người có quyền quyết định cuối
- Mốc Decision Freeze
Khi tài liệu này được chốt, đội phát triển mới có nền tảng để ước lượng, thiết kế và build đúng hướng.
Mẫu checklist dùng ngay trong buổi làm rõ đầu tiên
- Hệ thống có bao nhiêu nhóm người dùng thật sự khác nhau?
- Mỗi nhóm phải hoàn thành công việc gì trong hệ thống?
- Nhóm nào được tạo, sửa, xóa, duyệt, từ chối?
- Quyền nào áp dụng toàn hệ thống, quyền nào chỉ trong phạm vi đội, phòng ban hoặc chi nhánh?
- Sau khi một thao tác đã duyệt, ai còn được sửa?
- Nếu xảy ra sai sót, ai được xử lý ngoại lệ?
- Có trường hợp một người kiêm nhiều vai trò không? Nếu có, ưu tiên quyền theo nguyên tắc nào?
- Phiên bản đầu tiên bắt buộc phải có những quyền nào?
- Những quyền nào biết là cần nhưng sẽ để ở giai đoạn sau?
- Khi có bất đồng, ai là người chốt cuối?
Các phản đối thường gặp từ founder và cách xử lý
"Cứ làm trước đi, sau này sửa"
Có thể sửa sau, nhưng phải biết cái gì đang trì hoãn quyết định hợp lý và cái gì đang đẩy rủi ro sang giai đoạn build. Nếu chưa chốt role và quyền hạn, chi phí sửa sau thường không chỉ là sửa giao diện, mà là sửa logic, sửa dữ liệu, sửa phân quyền và đôi khi phải làm lại cả luồng.
"Bên tôi vận hành linh hoạt, khó chốt cứng"
Linh hoạt không có nghĩa là mơ hồ. Hãy giữ linh hoạt ở nơi cần linh hoạt, nhưng vẫn phải chỉ định ai có quyền mở ngoại lệ và trong giới hạn nào. Nếu không, hệ thống sẽ không bảo vệ được vận hành.
"Role này chắc sau này tính tiếp"
Nếu role đó ảnh hưởng đến kiến trúc quyền, phạm vi dữ liệu hoặc luồng duyệt, thì không nên để sau. Ít nhất phải quyết định rõ là chưa hỗ trợ ở phiên bản đầu và ghi vào scope out.
"Ai cũng cần xem được hết cho tiện"
Đây là quyết định nhanh ở hiện tại nhưng rủi ro lớn về bảo mật, trách nhiệm và sai lệch dữ liệu. Nên hỏi lại: xem hết để làm gì, xem trong bao lâu, và có thật mọi người đều cần như nhau không?
Kết luận
Chốt user role và quyền hạn trước khi thi công không phải là thủ tục giấy tờ. Đây là bước chuyển bài toán từ mức ý tưởng sang mức có thể build. Khi dự án đạt Level 3, đội ngũ sẽ không chỉ biết mình đang làm gì, mà còn biết rõ quyết định trước khi build, phần nào nằm trong scope, phần nào để sau, và ai có quyền chốt khi có mâu thuẫn.
Đầu ra lý tưởng không phải một tài liệu dài, mà là một bản mô tả ngắn gọn nhưng đủ điều kiện thi công: role rõ, quyền rõ, ngoại lệ rõ, scope rõ, trade-off rõ và Decision Freeze rõ. Khi đó việc xây phần mềm mới thật sự bắt đầu trên một nền móng chắc.
