项目管理工具的权限往往比想象中粗：要么全员可见，要么只有管理员能改。上线前先画一张「谁能看到什么」的表。
项目管理工具选型时，大家比的是看板好不好看、能不能自动提醒。真正会在半年后出问题的，是权限。
一、可见范围
三种常见模型：
- **全员可见**：简单，但薪酬相关的项目、客户投诉、人事流程也会被所有人看到 - **按项目隔离**：成员只看到自己参与的项目，最常用 - **按空间/团队隔离**：适合多部门共用一套系统
选型时最容易忽略的是「默认可见性」。新建项目默认全员可见，意味着有人忘了改设置，内部信息就公开了。
二、编辑粒度
能不能区分「看」「评论」「改状态」「改内容」「删」？
很多工具把这几件事合并成「成员」一个角色：给了成员，就等于给了删除权。这在跨部门协作时很危险——外部同事能删掉你的验收标准。
至少要能分出三档：只读、可评论、可编辑。
三、访客与外部协作
和客户、外包、供应商协作时，需要「访客」角色：只看得到被指定的任务，看不到整个项目。
如果工具没有访客角色，实际做法会变成「给对方开一个正式账号」，权限过大。或者退化成截图发微信，协作记录全丢。
四、离职交接
这一项几乎没人选型时问，但每次有人离职都会痛一次。
要确认三件事：能不能批量转移任务归属、离职成员的账号停用后历史记录还在不在、以及自动化规则（比如「指派给某人」）会不会因为账号停用而失效。
画一张表
上线前，用一张表把权限讲清楚：
| 角色 | 能看到 | 能改 | 能删 | | --- | --- | --- | --- | | 项目负责人 | 本项目全部 | 全部 | 任务与附件 | | 成员 | 本项目全部 | 自己负责的任务 | 无 | | 访客 | 指定任务 | 评论 | 无 | | 管理员 | 全部 | 全部 | 全部 |
这张表的价值不在好看，而在于逼着团队确认「谁能看到什么」。写完常常会发现两件事：某个角色权限过大，或者某个流程根本没有对应角色。
一个提醒
权限设计不要追求一次到位。先按最小权限开，遇到阻力再放开，比一开始全开再收紧容易得多——后者往往伴随着「为什么我的权限没了」的情绪。