高效率办公指南：制定专属团队的工作流

每个人都讨厌被控制在“流程”下，但是我们必须清楚一个事实：如果没有既定的工作流，我们的工作将是一团乱麻。

每个软件开发团队都有一个用来完成工作的流程。将流程规范化并将其建立为工作流——使其结构清晰且可重复，从而使其具有可伸缩性。我们采用反复论证的方式来创建和使用工作流，因为它帮助我们更快地实现目标，并体现了我们的团队文化。

从简单的开始做起

当为团队实现工作流时，不要先花费数周时间来设计流程，我们建议从简单的开始做起。过于复杂的工作流很难理解和采用，更不用说让团队来适应了。

对于软件研发团队，我们推荐以下基本工作流状态:

在任务追踪中，这些状态的使用构成了工作流的转换，完成阶段性任务并改变状态后，任务将自动跳转至下一个工作流。

有些软件开发团队在他们的工作流中也会包含额外的任务状态，以帮助他们更精确地进行追踪。

在实际应用中，面对众多产品研发任务，只有基本的工作流程并不能满足不同研发团队的需求。所以，在“未开始-进行中-审查中-完成”的基本工作流的基础上，Worktile还设置了多个任务类型（比如，敏捷任务、测试用例、移动原型设计等）：

并根据实际情况添加了“排队中”、“阻塞”、“跳过”、“失败”等细节性任务状态，针对任务中所有可能涉及到的情况，进一步完善了研发任务工作流。

工作流中的每个状态不需要由不同的人处理。随着敏捷团队的成熟，开发人员要处理从设计到交付越来越多的工作。毕竟，能够处理内部多样性的复杂工作是敏捷团队的特征之一。

在每次的复盘会中应当多注意团队遇到的痛点。每个团队喜欢的项目、掌握的技术和使用的方法都不尽相同，这就是为什么配置和选择具有高度灵活性的工作流很重要。

太多的团队为了适应特定的工具而牺牲了他们的工作风格，这可能会使团队成员感到沮丧；因此，他们会开始刻意避免使用该工具，这样就会对工作效率有所影响。我们使用工具的目的是为了简化操作流程，提高工作效率，而不是为了使用而使用。

因此，除了有通用模板，Worktile还针对项目的多样性，允许项目管理者在配置中心自定义，从任务阶段、状态、标签到任务面板，以高灵活性来更好的适用于不同团队的工作风格，避免出现让团队工作习惯来适应工具的情况。

刚接触敏捷开发或者不具备跨职能技术成员的团队，工作流程常常会以“迷你瀑布流”的形式告终。例如，设计使用模型启动工作项、开发负责实现、测试确认质量等，每个任务在前一个状态完成之前都被停滞，这种描述听起来是不是很熟悉？没错，又回归了瀑布流开发。但是我们可以用敏捷工作流改善这种情况，让开发变得更容易。

共享工作流程

当你已经熟悉基本工作流并准备自定义它时，记得为团队流程中每种类型的工作都创建一个状态。基本构思、设计、开发、代码评审和测试在功能上是不同的，都可以是单独的状态。我们设定工作流的目标就好比是刻出一座简洁的雕像，每一个流程节点都可以清晰地传达出这件作品所处的阶段。

在Worktile，项目状态和任务也可以与公司组织的其他团队成员共享，用【全局关联】的方式实现快速一对一沟通。这样一来，我们在构建工作流时，可以考虑哪些指标是最重要的，哪些非团队成员也可以借鉴。

一个设计良好的工作流可以反映出以下问题:

• 团队完成了哪些工作?
• 积压的工作量是在增加还是与团队同步?
• 每个状态中有多少项任务?
• 是否有瓶颈阻碍了团队的发展?
• 完成一项普通任务需要多长时间?
• 有多少工作项目第一次没有通过我们制定的标准?

扩展工作流的挑战

拥有多个敏捷团队的企业或组织在工作流方面将面临特殊的挑战。我们完全可以理解，团队通常希望优化他们自己的工作流，以反映他们独特的流程和文化。但是，在同一个项目中，不同的团队使用不同的流程就可能会出现问题。

共同工作的敏捷团队可以从共享一致的工作流中获益。使用相同的工作流可以使敏捷团队之间的工作转换更容易，因为它们使用相同的约定来定义和交付工作。而创建一个一致的流程通常涉及到两个团队的一些意见交换和讨论，不过这也是相互学习的好机会，有助于最终够创造出更好更适用的工作流程。

无论您团队的工作流是什么，开发它的过程应当保持敏捷。后续需要不时在复盘会中讨论它，并随着团队文化和组织的变化做相应的调整。