任务管理
任务把一个协作请求变成有人能够承担、推进并结束的行动。任务管理用于减少“我以为你会做”“一直在推进”“做完了但不是想要的结果”这类断裂。为每件小事填写完整表单只会增加成本。
什么情况下需要任务
一句即时回复能够完成的低风险请求，通常不需要额外创建任务。工作跨越较长时间、需要交接、依赖多人、存在截止风险，或完成情况需要被其他人看到时，应进入可追踪的任务载体。
讨论话题、长期目标和提醒不自动等于任务。任务意味着有人接受推进责任，并且存在可以判断工作是否结束的结果。尚未确定是否要做的事情，应先作为问题或提案讨论，避免用任务状态制造已经承诺的假象。
Issue、PR 与任务的区分
Issue（问题报告）、PR（代码变更）和任务是三种不同性质的事物，不应在协作中直接等同。
Issue 是记录。一条 Issue 可以记录缺陷、产品建议、技术方向或待讨论问题，任何人可以随时提出。提出 Issue 不意味着有人承诺处理，接收者也无需因此调整当前工作。尚未决定是否要做的事，应先停留在 Issue 阶段进行讨论和判断。
任务是承诺。有人接受推进责任、存在可验证完成条件的工作单元。只有部分 Issue 最终转为任务；这个转换本身是一个决策，需要明确谁决定做、为什么现在做、谁负责推进以及完成后如何验证。没有经过这个决策的 Issue 仍是待讨论问题，不是待执行工作。
PR 是实现手段。PR 应关联一个已确认的任务或记录在案的决策。发出 PR 的人有责任说明它解决什么问题、关联哪个决策或任务。无任务或决策记录的 PR，接收者没有审阅义务，可以视作实验性代码，不保证被 review 或合入。
缺少这个区分时，常见的结果是：一条 Issue 被提出后，另一个人直接编写代码、发起 PR 并要求审阅，但没有任何人确认过这件事是否应该在当前周期处理。每一层都在预设承诺，接受方却无法判断优先级、影响范围和完成条件。
影响明确、可逆且参与者处于同一上下文中的小修改（如修复文档错字），可以跳过上述区分。可能影响功能行为、用户接口、数据安全或需要多人协调的变更，应当经过 Issue→任务→PR 的清晰转换。
发起任务要让对方能够行动
任务至少应让接收者理解要发生什么改变、谁负责推进，以及怎样知道这件事已经结束。所需上下文与工作复杂度成比例。
简单任务可能一句话和一个负责人就足够。复杂任务通常还需要解释为什么现在做、预期结果、重要约束、依赖、时间边界和验收方式。这些内容可以存在于链接的方案或项目背景中，不必复制成固定字段。
“尽快处理”“跟进一下”或只转发一段聊天，通常没有提供足够行动信息。发起者不一定要提前知道完整解决方案，但应说明观察到的问题、期望谁作出什么判断，以及下一次需要确认的时间。
负责人承担推进责任
每个处于执行中的任务应有一个能够推动它走向结论的人。负责人可以请求帮助、拆分工作或调整方案，不代表独自完成所有内容，也不代表拥有超出职责边界的决定权。
任务被指派后，接收者仍需确认是否接受。对时间、范围或能力存在疑问时，应主动协商或拒绝，避免任务默默停留在“待处理”。跨团队请求尤其需要给对方接受和重新安排优先级的空间。
负责人变化时，应明确交接当前状态和下一步。仅修改头像或字段而不转移上下文，不构成有效交接。
时间预期用于协调，不用于制造虚假确定性
有真实时间约束的任务应说明为什么这个时间重要。截止时间可以来自外部承诺、安全风险或其他工作的依赖，也可以是用于重新确认方向的时间点。不要把任意日期写成硬期限来获得关注。
无法可靠估计完成时间时，可以约定下一次更新或判断点。相比一个没有依据的精确日期，“周三前完成风险验证并重新估计”更能帮助相关人员安排工作。
紧急程度应被明确表达并由实际影响支持。反复催促不会自动提高优先级，只会增加中断成本。
状态更新要帮助别人作出判断
任务持续时间足以让相关人员失去上下文，或变化会影响依赖方时，需要更新状态。频率应由风险和依赖决定，不必为没有新信息的短任务建立固定汇报节奏。
有效更新说明发生了什么变化、下一步是什么、是否存在风险，以及需要谁响应。“处理中”“已经同步”只有在读者不需要据此行动时才足够。
更新应留在任务或其权威工作载体中。聊天可以提醒相关人员，但不能让完整状态分散在多个私聊和群组。
受阻是一种需要处理的状态
负责人无法继续推进时，应说明阻塞来自什么、已经尝试了什么、影响哪些承诺，以及需要谁提供何种帮助。无法确定解决时间时，至少约定何时重新判断。
阻塞持续存在，可能表示依赖没有被接受、任务范围过大、优先级不真实或原目标已经失效。此时应调整范围、重新分配、暂停或取消，而不是不断更新相同的“仍在阻塞”。
公开阻塞可以让有能力帮助的人获得上下文。团队应改善造成阻塞的工作条件，并保护那些尽早暴露风险的人免受惩罚。
结束任务需要留下结果
完成意味着预期改变已经发生，而不只是负责人停止工作。结果可以是交付物、决定、验证结论或明确的“不再继续”。复杂任务应让相关人员能够从任务找到结果及其验证方式。
验收是确认共同预期的过程，不必总由单独角色或正式流程完成。低风险任务可以由负责人自证；高影响或专业性强的结果可能需要指定人员确认。
取消也是有效结论。应留下足够理由，避免后来者把同一件事误认为被遗忘并重新发起。结束后出现新的目标时，是否新建任务取决于它是否需要独立责任和上下文，而不是为了保持状态整洁。