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

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

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

从简单的开始做起

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

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

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

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

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

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

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

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

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

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

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

共享工作流程

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

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

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

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

扩展工作流的挑战

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

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

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