Một đội dịch vụ B2B dùng Google Sheet để theo dõi khách hàng. Khi chuyển sang MVP nội bộ, sales cập nhật cơ hội, delivery xem phạm vi đã bán, kế toán theo dõi thanh toán và founder duyệt giảm giá. Bản mô tả ban đầu chỉ ghi: "mỗi người đăng nhập bằng tài khoản riêng".
Dev vẫn phải hỏi sales được xem khách nào, delivery có được sửa báo giá không, ai được xuất công nợ và quyền nào thay đổi khi nhân sự chuyển nhóm. Trả lời rải rác trong lúc code dễ làm quyền truy cập lệch giữa giao diện, API và dữ liệu.
Bắt đầu từ dữ liệu và hành động
Một màn hình có thể chứa nhiều loại dữ liệu với mức nhạy cảm khác nhau. Trang chi tiết khách hàng chẳng hạn có thông tin liên hệ, lịch sử trao đổi, giá bán và trạng thái thanh toán. Cho phép một vai trò mở trang không đồng nghĩa họ được xem hoặc sửa mọi trường trên đó.
Đội nên liệt kê khách hàng, cơ hội bán hàng, báo giá, hợp đồng, việc bàn giao và thanh toán. Với mỗi đối tượng, ghi rõ các hành động xem, tạo, sửa, chuyển trạng thái, duyệt, tải xuống và xóa. Cách này tách quyền sửa báo giá khỏi quyền duyệt báo giá.
Vai trò cần đi cùng phạm vi và trạng thái
Tên vai trò như sales, quản lý hoặc kế toán chưa mô tả đủ quyền. Hai nhân viên sales có thể cùng vai trò nhưng chỉ được xem khách hàng mình phụ trách. Một quy tắc rõ sẽ có dạng: "sales được sửa thông tin liên hệ của khách mình phụ trách khi cơ hội chưa chuyển sang trạng thái đã ký". Kế toán có thể xem thanh toán nhưng không cần sửa proposal. Delivery có thể đọc phạm vi đã bán nhưng không được đổi giá.
Quy trình thiết kế phân quyền cho phiên bản đầu
1. Liệt kê dữ liệu cần bảo vệ
Người phụ trách sản phẩm cùng sales, delivery và kế toán ghi các đối tượng dữ liệu trong MVP, sau đó đánh dấu phần nhạy cảm và phần cần chia sẻ.
2. Lập ma trận vai trò và hành động
Các hàng là vai trò, các cột là hành động. Mỗi ô ghi "được phép", "không được phép" hoặc điều kiện cụ thể. Tránh cụm "quản lý đầy đủ" vì dễ hiểu khác nhau.
3. Thêm phạm vi và điều kiện trạng thái
Đội xác định quyền áp dụng cho dữ liệu cá nhân, theo nhóm hay toàn công ty. Báo giá ở bản nháp có thể cho sales sửa, nhưng sau khi gửi khách chỉ người có thẩm quyền mới được mở lại.
4. Chốt ngoại lệ và người phê duyệt
Xuất dữ liệu hàng loạt, xóa hồ sơ đã có giao dịch hoặc giảm giá đặc biệt cần quy định riêng. MVP phải cho biết yêu cầu đang chờ ai.
5. Chuyển quy tắc thành test case
Mỗi quyền cần trường hợp được phép và bị từ chối. Test cả giao diện lẫn API, bởi ẩn nút không ngăn được yêu cầu gửi trực tiếp.
Phân quyền phải được kiểm tra ở phía hệ thống
Ẩn nút hoặc menu theo vai trò không bảo vệ được dữ liệu. Nếu API không kiểm tra quyền, người dùng vẫn có thể sửa tham số để truy cập hồ sơ ngoài phạm vi. Phía máy chủ cần xác thực người dùng, hành động, phạm vi và trạng thái trước khi đọc hoặc thay đổi dữ liệu. Hệ thống cũng không nên tiết lộ hồ sơ cho người không có quyền xem.
Bài cách chuyển ghi chú sản phẩm thành spec và test case trình bày cách viết điều kiện và kết quả mong đợi để dev cùng QA kiểm tra.
Checklist trước khi duyệt phạm vi phân quyền
Dữ liệu và hành động
- Đã liệt kê các đối tượng dữ liệu trong phiên bản đầu.
- Quyền xem, sửa, duyệt, xóa và xuất được tách riêng.
- Trường dữ liệu nhạy cảm có quy tắc hiển thị cụ thể.
Phạm vi và thay đổi nhân sự
- Mỗi vai trò có phạm vi cá nhân, theo nhóm hoặc toàn doanh nghiệp.
- Có cách thu hồi quyền khi nhân sự nghỉ việc hoặc chuyển nhóm.
- Tài khoản mới không tự nhận quyền cao hơn mức cần thiết.
Kiểm thử
- Có test case cho truy cập hợp lệ và truy cập bị từ chối.
- API kiểm tra quyền độc lập với trạng thái hiển thị trên giao diện.
- Ngoại lệ có người phê duyệt và kết quả rõ ràng.
Giữ mô hình đủ nhỏ để đội vận hành được
Đội nhỏ có thể bắt đầu với vài vai trò bám sát cách phân công hiện tại. Không nên dùng chung tài khoản quản trị hoặc cấp quyền rộng chỉ để giảm thời gian thiết lập. Nếu một người kiêm nhiều nhiệm vụ, hệ thống có thể gán nhiều vai trò nhưng phải ngăn trường hợp người đó vừa tạo vừa tự duyệt cùng một giao dịch.
Đầu ra cần có trước khi phát triển
Bộ tài liệu tối thiểu gồm danh sách dữ liệu, ma trận vai trò và hành động, quy tắc phạm vi, ngoại lệ cần duyệt và test case chính. Người phụ trách sản phẩm chốt quy tắc nghiệp vụ. Tech lead xác nhận cách kiểm tra quyền ở giao diện, API và tầng dữ liệu.
Đội có thể thử ma trận trên một luồng, ví dụ tạo và duyệt báo giá. Khi quy tắc chạy đúng, cùng cấu trúc được áp dụng cho hợp đồng, bàn giao hoặc thanh toán. Dịch vụ Product Development của Auranium có thể hỗ trợ chốt phạm vi, viết quy tắc phân quyền và đưa chúng vào tiêu chí bàn giao của MVP.