创建任务
LadVen OS 这套企业操作系统帮助在需要具体结果、负责人和透明执行过程的地方提出任务。好的任务会减少多余确认:执行人理解要做什么、为什么需要、材料在哪里,以及结果如何检查。
好的任务提出方式会把约定变成可检查任务:结果、负责人、期限、上下文、材料和检查标准。
什么时候创建任务
当工作需要被分配、讨论并推进到结果时,适合创建任务。没有交付结果的短问题更适合用评论或聊天;重复流程则更适合使用带检查清单或模板的任务。
当存在以下内容时,请创建独立任务:
- 可检查的预期结果;
- 一个主要负责人;
- 期限,或说明为什么暂时没有期限;
- 上下文:客户、项目、文档、文件或链接;
- 需要看到执行过程的参与者。
创建前
先表述结果,而不是动作。标题应回答:“什么应该准备好?”
好的示例:
- “为客户准备商业提案”;
- “确认试点启动日期”;
- “检查合同并标记修改”。
不好的示例:
- “客户”;
- “看一下”;
- “重要”。
如何填写任务
必填最低信息
保存前,任务中必须清楚四件事:要得到什么结果,谁对结果负责,什么时候需要结果,以及按什么标志验收。
| 要填写什么 | 为什么需要 | 什么是不够的 |
|---|---|---|
| 标题 | 让任务能在列表和通知中快速识别。 | 没有结果的泛泛主题:“客户”“合同”“重要”。 |
| 结果描述 | 让执行人理解上下文、预期结果和完成标准。 | 只有一个链接、无说明的转发文本,或“需要看一下”。 |
| 负责人 | 让结果有一个所有者。 | 多个事实负责人,或参与者没有角色。 |
| 期限或缺少期限的原因 | 让团队能计划工作,不丢失紧急任务。 | 没有原因的“今天”,或没有说明的空期限。 |
文件、检查清单、项目、客户、工作组、标签、计划时间和观察者不是每个任务都需要。只有当它们帮助执行或检查工作时才添加。
标题
标题应简短具体。不要把所有上下文都放进标题:标题保留结果,细节放到描述中。
好的格式:
动词 + 结果 + 对象
示例:
- “准备会议演示文稿”;
- “更新合同条款”;
- “检查网络研讨会参与者名单”。
结果描述
描述回答三个问题:为什么需要这项工作,具体要做什么,如何判断任务已完成。对负责人来说,这是不另开会议也能传达期望的方式;对执行人来说,这是工作会被接受或退回修改的标准来源。
推荐结构:
上下文:
任务为什么出现,以及它与什么有关。
需要做什么:
1. 第一步。
2. 第二步。
3. 最终交付什么。
完成标准:
- 结果可以打开或检查;
- 重要修改已考虑;
- 参与者已收到最终版本。
如果任务中有链接,请在旁边加说明。单独一个链接没有上下文,会迫使执行人重新弄清要做什么。
好的结果描述应能无需猜测地检查:
- 应创建、修正、确认或发送什么;
- 原始材料在哪里;
- 谁验收结果;
- 哪个文件、链接、评论或变更确认完成;
- 如果有范围扩大的风险,哪些内容不属于本任务。
差的描述会留下个人解释空间:“正常做完”“弄明白”“看看客户”“把会议都准备好”。应改成可见结果:文档、列表、决定、已发送邮件、已确认版本或已完成检查。
负责人
任务应只有一个主要负责人。如果多人参与,请指定一个结果所有者,其余人作为协作执行人或观察者添加。
负责人对最终结果负责,而不是对每个单独步骤负责。如果不同人员有独立结果,最好创建几个关联任务。
期限
期限应帮助计划,而不是制造虚假紧急感。请指定真正需要结果的日期。
只有工作确实阻塞当天时才使用“今天”。如果日期暂不明确,请在描述中写明,并约定谁来确认期限。
如果任务依赖外部事件,请在描述中说明,例如“客户回复后确认期限”或“需要在 5 月 24 日会议前完成”。这样参与者能理解为什么选择这个日期,以及什么时候需要重新查看。
优先级和计划时间
优先级说明任务如何与其他工作比较。高优先级不是给“意义重要”的任务使用,而是给应早于正常队列处理的任务使用。
计划时间帮助提前约定工作量。如果任务影响团队负载、需要评估,或之后要比较计划与实际,请填写计划时间。
不要用高优先级和短期限代替正常描述。如果任务紧急,请在描述中说明原因。
预评估和检查
如果工作需要预评估,请在开始执行前固定下来。这样执行人会先澄清工作量,而不是带着错误预期开始做。
结果检查适用于不只是“做了动作”,而是必须验收最终结果的任务:文档、提案、合同、清单、客户回复、准备好的材料。
参与者
按角色添加参与者:
- 提出人表述结果并验收工作;
- 负责人推动任务走向结果;
- 协作执行人完成部分工作;
- 观察者跟进上下文,但不负责执行。
不要“以防万一”添加观察者。多余通知会降低对重要任务的注意力。
如果负责人只需要最终结果,不一定从一开始就把他加为观察者。可以让他不在任务中,等结果准备好时在评论中提及。只有当这个人需要在执行过程中看到进展、风险和决定时,观察者才是必要的。
文件、CRM 和文档
附加没有它们就无法完成任务的材料:合同、简报、客户文件、表格、文档链接或 CRM 实体。附件应帮助执行人无需额外搜索就能开始工作。
有用的附件:
- 属于当前任务,而不是一般讨论;
- 有清晰名称,或在描述中有说明;
- 是当前版本,而不是旧草稿;
- 参与工作的人有访问权限;
- 不包含多余的私人或商业数据。
如果文件只是参考材料,请在描述中说明。如果文件应成为工作结果,请把它写进完成标准。
| 情况 | 附加什么 | 描述中写什么 |
|---|---|---|
| 需要准备提案 | 客户简报、提案模板 | 使用哪个模板以及要填写什么 |
| 需要检查合同 | 合同当前版本 | 检查哪些章节以及在哪里标记修改 |
| 需要更新列表 | 包含列表的表格或文档 | 更新哪些列,以及如何判断列表已准备好 |
不要只因为文件“可能有用”就附加。多余材料会像多余观察者一样让任务变复杂。
项目、客户和工作组
如果没有关联后续会难以找到上下文,请把任务关联到项目、客户或客户项目。销售、实施、文档和重复请求中的任务尤其需要这样做。
当任务属于稳定团队或方向时,工作组很有用。不要只为了排序而选择工作组:如果关联不能帮助参与者理解上下文,最好不选。
标签
标签用于快速切片和重复流程,例如 合同、试点、审批、客户紧急。标签应帮助之后查找或分组任务。
不要用标签重复状态、负责人或项目已经表达的信息。否则标签列表很快失去价值。
检查清单
如果任务由几个可检查步骤组成,请添加检查清单。好的检查清单项应描述一个可以标记完成的动作。
检查清单尤其适合:
- 工作按流程重复;
- 结果依赖多个必须检查的动作;
- 多个参与者完成不同部分;
- 提出人需要不读完整讨论也能快速看进度。
把项目写成动作:
好的示例:
- “检查客户资料”;
- “在模板中填写费用”;
- “把最终版本交给审批”。
不好的示例:
- “资料”;
- “商业”;
- “弄清合同”。
如果某一项需要单独讨论,不要把它藏在检查清单里。请把说明放到任务描述中,或在评论里提问。
复杂流程可以谨慎使用嵌套:上层项表示阶段,子项表示阶段内的具体动作。如果嵌套让列表难以快速阅读,最好使用几个普通项或单独关联任务。
如何在 LadVen OS 中创建任务
- 打开 LadVen OS 的任务区。
- 点击创建新任务的操作。
- 填写标题、描述、负责人和期限。
- 如果优先级、计划时间或预评估会影响执行,请填写它们。
- 如果任务与项目、客户、工作组、标签或文档有关,请添加。
- 附加有用文件:只附加执行或检查结果所需的当前材料。
- 如果工作包含多个步骤或检查,请添加检查清单。
- 检查参与者、文件访问、期限和完成标准。
- 保存任务。
好任务示例
标题:
为客户准备商业提案
描述:
上下文:
客户请求试点启动方案。需要在会议前发送最终版本。
需要做什么:
1. 检查简报中的输入信息。
2. 填写商业提案模板。
3. 添加启动期限和费用。
4. 将版本提交给提出人审批。
完成标准:
- 文档中没有草稿评论;
- 费用和期限已填写;
- 最终版本已附加到任务中。
检查清单:
- 检查简报中的输入信息。
- 填写提案模板。
- 添加期限和费用。
- 附加最终版本。
- 提交审批。
保存前检查什么
- 标题描述结果,而不是泛泛主题。
- 描述中有上下文、步骤和完成标准。
- 只有一个负责人,并且角色清楚。
- 期限真实,或说明了暂时没有期限的原因。
- 文件、链接和 CRM 实体确实是工作所需。
- 观察者是有意添加的。
- 检查清单由可检查动作组成。
- 如果任务需要验收,说明由谁、在哪里、按什么检查。
创建后
检查任务是否出现在列表中,参与者是否能访问上下文。需要澄清时,在任务评论中提问,不要只发私信,这样决定会留在工作上下文中。
如果任务创建错误,请尽快修正标题、参与者或期限。任务整理得越早,参与者收到的多余通知和确认越少。
常见错误
| 错误 | 会造成什么问题 | 如何修正 |
|---|---|---|
| 提出任务时没有结果。 | 执行人不知道要交付什么供验收。 | 表述最终结果:文件、决定、列表、审批、已发送消息或已完成检查。 |
| 标题过于笼统。 | 任务难以在列表中找到,也难以与相似任务区分。 | 用动作和结果开头:“准备”“检查”“确认”“更新”。 |
| 描述中只有链接。 | 参与者需要重新弄清打开什么以及对材料做什么。 | 在链接旁加简短说明和完成标准。 |
| 责任实际上分散给多人。 | 没有人拥有最终结果。 | 指定一个负责人,其余人作为协作执行人并说明各自部分。 |
| 观察者是“为了看见”而添加。 | 通知变成噪音,重要任务被忽略。 | 只留下确实需要进度、风险或决定上下文的人。 |
| 期限设置成“今天”但没有真实原因。 | 团队看到虚假紧急,计划失真。 | 指定真实需要日期,并在描述中说明原因。 |
| 附件没有版本或访问检查。 | 执行人可能按旧文件工作,或打不开材料。 | 附加当前版本并检查访问权限。 |
| 检查清单写的是想法而不是动作。 | 进度看起来已推进,但结果无法验收。 | 把每项改成可检查动作。 |