工作就是工作

工作是为了实现某个目标或结果而进行的活动。这不仅包括您正在从事的产品或项目，还包括您为公司执行的所有任务。在我与的一些团队中，有些人将多达 50% 的工作时间花在项目/产品团队以外的任务上。有些人是团队负责人，需要参与与组织团队成员的会议和承担责任；有些人是工作委员会成员；有些人参加个人发展路径的培训；还有一些人则必须修复过去项目中的 bug 和现场问题。

许多任务是无法从团队成员那里去除的。团队成员可能喜欢这些任务，也可能不喜欢，但它们通常是个人发展的重要组成部分。

这种工作的一个问题是，这些任务的优先级和协调工作由个人在其团队上下文之外决定。谁来决定，修复开发者曾经参与过的系统中的 bug，是否应该优先于当前项目中的 bug？通常，个人会自己规划和优先处理这些任务。这常常导致更多的前期规划。当团队成员在 sprint 开始时报告可用时间时，团队就开始围绕这些事件来规划当前任务。这可能会阻止整个团队建立拉取 (pull) 流程，反而迫使他们规划依赖任务并将其分配给个别团队成员（推送式规划）。

为了解决这个问题，您应该让团队看到所有的工作，并将其加入到团队的待办事项 (backlog) 中。您是否在工作委员会中？将其加入待办事项中。您是否有培训任务？将其加入待办事项中。

因此，第一步是弄清楚您的团队正在执行哪种类型的工作，并将所有内容收集到一个待办事项中。

第二步是简化。每个人都能把事情弄得更复杂——但要做到简化却需要一些天赋。因此，在大多数公司中，随着时间的推移，流程和表单往往会变得越来越复杂。我曾见过一些表单，其中包含 300 个字段，并基于这些字段有复杂的路由规则——仅仅是为了处理现场故障事件。不要把这些复杂的流程移植到您的待办事项中。无论后台的流程如何，工作都有一个明确的触发点，由您的团队处理，然后离开您的责任范围——从您的角度来看，它就完成了。一个流程或工单可能会导致待办事项中多个小工作项的产生。每个工作项应简化为 "待办"、"进行中" 和 "已完成"。