任务参与者
在 LadVen OS 中，参与者决定谁表述结果、谁负责执行、谁协助完成，谁只关注工作进展。请按角色添加人员，而不是“以防万一”把所有相关人员都加入任务：多余参与者会稀释责任，也会制造不必要的通知。
主要规则
每个任务应有一个主要负责人。他不一定亲自完成每一步，但要负责把任务推进到可检查的结果。
如果几个人各自交付独立结果，最好创建多个关联任务。如果一个人负责总体结果，其他人完成部分工作，请保留一个负责人，并把其他人添加为协作执行人。
角色
提出人
提出人表述结果、解释上下文并验收工作。通常这是需要任务结果的人，或者对客户、负责人、团队承担流程责任的人。
提出人应能回答澄清问题。如果提出人无法检查结果，请提前说明谁会代替他验收：写在描述、评论中，或通过观察者角色体现。
负责人
负责人把任务推进到结果：更新状态、提出问题、协调协作执行人，并报告阻塞。
请把负责人分配给真正能把任务带到结果的人。不要把负责人角色当成“通知所有人”的方法：当事实上有多个负责人时，没有人清楚谁对最终完成作决定。
协作执行人
协作执行人用于其他人承担部分工作的情况：准备文件、给出技术评估、确认文本、收集数据、检查单独模块。
只有当人员有明确工作部分时才添加为协作执行人。最好在描述、检查清单或评论中固定这部分工作：协作执行人知道自己负责什么，主要负责人也能看到进度。
观察者
观察者看到任务进展和上下文，但不负责执行。这适合负责人、相邻团队、客户经理，或需要了解决定的人。
不要“以防万一”添加观察者。如果某人只需要知道最终结果，更合适的做法是在结果准备好后在评论中提及他，或发送任务链接。
工作场景中的角色分配
角色不是为了形式上填满卡片，而是为了让工作可管理：谁作决定，谁负责结果，谁做部分工作，谁需要看到过程。
| 场景 | 如何分配参与者 | 为什么这样做 |
|---|---|---|
| 负责人给部门员工分配任务 | 负责人为提出人，员工为负责人。其他人不参与就不要添加。 | 结果有所有者，验收清楚。 |
| 经理处理客户请求，法务准备合同 | 经理或客户负责人为提出人，法务为负责人；经理可作为观察者或负责客户澄清的协作执行人。 | 文档责任不会和客户关系责任混在一起。 |
| 多个部门准备启动的独立部分 | 创建子任务或关联任务，分别指定负责人；总任务保留一个启动所有者。 | 每个结果都有自己的负责人，总启动不变成无所有者的指令列表。 |
| 只需要负责人确认 | 不把负责人指定为执行负责人。让他作为提出人、观察者，或在验收阶段评论提及。 | 执行负责人仍是推动工作的人，而不是只说“同意”的人。 |
| 某人需要提供数据给执行人 | 添加为协作执行人，并在描述或检查清单中写明他的部分。 | 参与者知道期待，也不会变成隐藏的共同所有者。 |
| 只需要告知最终结果 | 不提前添加观察者。结果准备好后在评论中说明或发送链接。 | 通知更少，注意力留给真正需要跟进的任务。 |
如果角色有争议，请问一个简单问题：“如果任务没有按时完成，谁负责？”这个人应是负责人，或是单独关联任务的所有者。
如何选择员工
创建或编辑任务时，使用参与者搜索。搜索可按姓名、姓氏或其他可用资料找到员工。
- 以创建或编辑模式打开任务。
- 进入参与者区块。
- 在所需角色的搜索字段中输入员工姓名。
- 从候选列表中选择员工。
- 如果列表按部门分组，展开需要的部门，并检查职位或团队。
- 如果确实需要，重复选择协作执行人和观察者。
- 保存任务或变更。
部门分组有助于区分同名人员，并选择正确团队的人。如果有多个相似员工，不只看姓名，也要看部门、头像、职位或其他可见资料。
如果在任务开始后添加参与者，不要只把人加入角色。请写一条简短评论：为什么接入、已经做了什么、需要看哪些文件或检查清单项、期待他执行什么动作。这样新参与者通过上下文进入任务，而不是靠猜测。
不可用候选人和权限
不是每个搜索到的员工都一定可被分配。候选人可能因权限、员工状态、项目、部门、工作组或客户上下文限制而不可用。
如果员工显示为不可用或无法选择：
- 检查任务是否属于受限项目、工作组、客户或 CRM 实体；
- 确认选择的是当前员工，而不是旧重复资料或停用资料；
- 检查此人是否能看到任务材料和附加文件；
- 如果确实需要参与，请让管理员或空间所有者配置访问权限。
不要通过添加为观察者或把材料转发到任务外来绕过权限。参与者应在 LadVen OS 内获得工作上下文访问权，否则讨论和验收会分散到不同渠道。
如何不稀释责任
保存前请回答三个问题：
- 谁验收结果；
- 谁负责任务被完成；
- 谁做单独部分，但不拥有最终结果。
如果第二个问题出现多个姓名，说明任务过宽或角色分配错误。请拆分为关联任务，指定一个结果所有者，或在检查清单中明确协作执行人的贡献。
责任被稀释的迹象：
- 负责人只是形式上的，实际决定等待另一个人；
- 协作执行人没有明确工作部分；
- 观察者被当成群发名单；
- 提出人无法检查结果；
- 任务描述了多个独立结果。
责任开始扩散时，不要通过增加参与者解决。先澄清任务结果。如果结果包含多个独立交付物，请拆分工作。如果结果只有一个，请选择一个负责人，并明确其他人的贡献。
实用公式：
负责人负责最终结果。
协作执行人负责自己的部分。
提出人负责期望清晰和验收。
观察者只负责自己跟进上下文。
在 LadVen OS 中如何操作
- 以创建或编辑模式打开任务。
- 检查提出人：他应理解预期结果和验收顺序。
- 通过参与者搜索找到负责人。
- 如果协作执行人有单独工作部分，就添加他们。
- 如果观察者需要看到执行进展，就添加他们。
- 按部门、职位或头像检查相似员工。
- 移除多余参与者和重复人员。
- 保存变更。
编辑已有任务后，保存完请在任务卡片中检查实际参与者列表。如果有人并行修改了参与者，请刷新任务，并确认保存后的人员组成符合约定。
保存前检查
- 只选择了一个负责人。
- 提出人能够验收或退回结果。
- 协作执行人理解自己的部分，且任务中已经固定。
- 观察者确实需要通知。
- 参与者来自当前员工资料，而不是旧重复资料。
- 每个参与者都能访问项目、客户、CRM 实体、文件和其他任务材料。
- 任务里没有只为“可见性”添加的人。
如何检查结果
保存后以查看模式打开任务，并检查参与者区块：
- 提出人、负责人、协作执行人和观察者显示在正确角色中；
- 负责人出现在任务列表和执行人筛选器中；
- 任务进入相关人员的“我的”“已分配”或“我参与的”视图；
- 参与者能打开任务并看到工作所需材料；
- 如果参与者在创建后被添加，他在任务中获得了上下文，而不是只有口头指令。
如果列表不正确，请立即修正角色。越早移除多余参与者或指定正确负责人，评论、通知和状态中的混乱越少。
更换负责人后
更换负责人是管理事件，而不只是字段修正。更换后应清楚为什么责任转移，以及工作以什么状态交接。
好的交接包括：
- 简短评论说明更换原因；
- 已完成什么、还剩什么；
- 新负责人需要检查哪些文件、检查清单和关联任务；
- 谁验收结果；
- 期限、计划时间或访问权限是否有风险。
不要在已有评论、文件、检查清单或客户上下文的任务中静默更换负责人。否则新的结果所有者必须手动恢复历史，负责人也会失去责任转移原因。
良好实践
- 一个可验收结果只指定一个负责人。
- 把协作执行人的贡献写在工作旁边：描述、检查清单或评论中。
- 只有当观察者需要看到执行过程、风险和决定时才添加。
- 更换负责人时写简短评论：为什么转移责任，以及已经完成什么。
- 对独立结果创建关联任务，而不是扩大一个卡片中的协作执行人列表。
- 工作开始前检查参与者对客户、项目、CRM、文档和文件的访问权限。
- 如果任务与客户有关，请让负责客户沟通的人参与上下文，但不要让他承担其他部门工作的执行责任。
- 负责人需要控制时，使用观察和最终评论，而不是形式上指定为负责人。
- 定期移除不再需要上下文的人。
- 角色有争议时回到验收标准：谁能检查结果，谁必须把结果完成。
常见错误
- 指定多个事实负责人，而不是一个结果所有者；
- 添加协作执行人但没有明确工作部分；
- 把观察者当成群发名单；
- 选择了另一个部门的同名人员；
- 保留旧的或停用的员工资料；
- 不检查参与者对文件、项目、客户或 CRM 上下文的访问权限；
- 更换负责人但不说明责任为什么转移；
- 用观察者绕过访问权限；
- 保存后不检查最终参与者列表；
- 为多个独立结果创建一个大任务。
此页面需要的截图
- 创建任务表单中的参与者区块：提出人、负责人、协作执行人和观察者。
- 带部门分组和头像的员工搜索。
- 一个负责人和多个协作执行人的清晰角色示例。
- 保存后查看模式中的参与者区块。
- 候选人不可用或受权限限制的状态。
- 客户或项目任务中参与者可访问关联材料的示例。