协作软件要注意角色分工

很多协作软件看起来功能不少，可一到多人一起干活时，大家很容易陷入一种熟悉的混乱里。有人不知道自己该做什么，有人不知道自己能向谁提要求，有人改了流程却没人同步，有人虽然挂着同一个职位名，实际边界却很模糊。结果是大家都在干，但总有种“接口没对上”的感觉。

协作乱很大一部分原因是“角色”没有被当成真正的底层机制来设计。很多系统嘴上说有角色，只是给不同用户分了几个名字，或者做了几种权限控制。没有把“负责接什么消息、发什么请求、怎么协商修改、什么时候换角色”这些事情做成系统骨架。于是角色虽然存在，实际却不顶用。所以这篇论文作者想做的就是把这件事讲清楚，并且给出一套可以落地的“骨架”。

一个协作系统，到底应该怎样让每个人都清楚三件事？第一，我现在该做什么。第二，我有权要求别人做什么。第三，如果我觉得分工不合理，怎么调整。作者认为，这三件事如果不被系统清楚表达出来，协作就只能靠人自己猜、自己协调、自己补漏洞。久而久之，系统越复杂，人越累。

作者对角色的理解很有意思：角色不是一个人的身份证明，也不只是职位名称，而更像是一个“包在这个人外面的工作壳”。这个壳有两面。一面是“责任”，也就是别人可以把什么事情发给你；另一面是“权利”，也就是你可以向谁发出请求、索取什么服务。论文里甚至专门用了一个很形象的说法：角色像是一个wrapper，把人和协作环境包起来。

作者给出三步协作过程：第一步，先谈角色，也就是先把分工谈明白。第二步，再把角色分配下去。第三步，大家按角色做事：一边接收跟自己职责相关的信息，一边发出自己权限范围内的请求。如果中途发现冲突、不满或者职责有问题，就退回去重新谈。这套流程听起来并不花哨，恰恰在补很多协作软件最缺的那一环：把“协商、分配、调整”本身也纳进系统逻辑里。

这篇论h出了一个正式模型，名字叫 E-CARGO：一个协作系统里，不只是有人和消息，还要把环境、类、代理、角色、群组和对象这些元素组织起来。如果把角色从系统里抽掉，很多看起来还在的东西就失去了组织能力。这也是为什么作者反复强调，角色不是装饰层，而是系统的中介层。

作者怎么理解角色，先看图 1。人并不是赤手空拳直接面对协作环境，而是通过角色来接消息、发请求、履行责任、行使权利。视角把很多过去混在一起的事情拆开了：人是人，角色是角色，群组是群组，环境是环境。分开以后，系统才有可能灵活地调角色、换角色、协商角色，而不是一改身份就把所有东西都绑死。

论文后半部分开始讲消息怎么分发、角色怎么批准给某个代理去扮演、群组怎么围着角色组织、接口怎么随着角色切换而变化。比如作者明确区分了四类界面：角色定义界面、角色扮演界面、角色协商界面、角色切换界面。

作者特别强调了一点：基于角色的系统反而可能更灵活。很多人觉得一旦把角色写死，大家就没法发挥了。论文的回答是否定的，只要消息模式设计得足够灵活，用户完全可以在角色允许的范围里创造新对象、发起新流程、申请调整职责。真正的问题不是“有没有角色”，而是“角色能不能被协商、被修改、被转移”。所以作者在定义基于角色协作时，专门把“角色可协商”、“角色可转移”、“角色可调整”列成核心属性。这里的立场很清楚：好角色不是把人锁死，而是把混乱变成可谈、可调、可落地的规则。

这篇论文把很多团队协作中的老毛病讲透了：职责模糊、边界打架、沟通靠临时想、流程总在软件外面补。E-CARGO 这个模型的意义，就是试着把这些原本散在组织学、心理学和软件工程里的问题压到同一个系统设计语言里。

作者在结尾也说得很清楚：他们实现的还是内核级机制，很多事情还没做完。比如更友好的客户端界面、真正分布式的平台、不同消息策略怎么设计、角色协商怎么做得更智能，这些都还是后续工作。

作者简介：朱海滨，加拿大尼皮辛大学计算机科学教授，IEEE Fellow、AAIA Fellow，E-CARGO模型与Role-Based Collaboration（RBC，基于角色的协作）方法的重要创立学者，现任IEEE Systems, Man, and Cybernetics Society系统科学与工程副主席。主要研究方向包括软件工程、编程技术、协作技术与系统、基于角色的协作、自适应协作，聚焦多智能体系统、群体绩效优化、群体角色分配及E-CARGO模型应用等问题。

ORCID：0000-0003-1922-1631

DOI: 10.1109/TSMCC.2006.875726

已收藏 0

点赞 0