缩短项目周期时间的8种方法以及为什么它很重要

我发现周期时间是产品经理需要跟踪的最被低估的指标之一。改善周期时间可以使交付更顺利，效率更高，学习更快，从长远来看，产品更好。

虽然有些人认为，跟踪顺利交付是团队或项目经理的责任，但现实是，在许多公司，产品经理既要做产品又要做交付。

---

目录

• 什么是周期时间？
• 为什么减少周期时间很重要？
• 减少周期时间的8种方法
  1. 尽可能地实现自动化
  2. 使用组件
  3. 优化代码审查过程
  4. 优化质量保证流程
  5. 发现并调查异常值
  6. 减少技术债务
  7. 用较小的碎片进行加工
  8. 运行实验

---

什么是周期时间？

周期时间是指从开始对一个项目进行工作到完成它的时间。

为什么减少周期时间很重要？

周期时间是衡量速度的主要标准之一–而速度是好的。缩短周期时间会导致：

• 更快的学习--我们发货越快，我们就能越快地评估结果
• 更高的灵活性 – 低周期时间使我们能够更快地做出反应，更容易改变方向。
• 更少的浪费 – 更快的交付导致更少的工作进展，这意味着更少的精力浪费在多任务和管理依赖性上。

此外，我发现周期时间是最值得跟踪的整体交付指标。实现低周期时间需要我们遵循最佳实践，例如：

• 限制正在进行的工作
• 消除等待时间
• 在小型、独立的PBI上工作
• 简化代码审查和质量保证过程
• 确保围绕PBIs的充分明确性
• 保持团队组成和文化的高效性

简而言之，低周期时间往往是健康交付过程的结果。

减少周期时间的8项策略

以下是我在过去几年与不同团队合作中发现的一些减少周期时间的最高杠杆策略。

1. 尽可能地实现自动化

自动化是关键。如果计算机可以做一些事情，人类就不应该去做。

CI/CD管道是减少周期时间的一个基石。如果可以为你做的话，你不想花时间做集成工作。

E2E测试自动化也是如此。如果你每次发布都要等上几天，因为QA要手动完成整个回归工作，你就做错了。

作为一个经验法则，交付过程的自动化程度越高，就越好。

2. 使用组件

如果你的产品已经过了最初的MVP阶段，可能是时候开始建立一个设计系统和可重用的组件了。

你不希望你的开发人员每次都要从头开始编码相同的按钮。用组件构建新的页面就像使用乐高积木。一切都已经在那里了。你所需要的是把它们正确地连接起来，以构建所需的图形。

从小处着手。给你的设计人员时间来为最常用的界面元素准备好文档化的组件。然后，给你的开发人员空间来建立一个组件库。

这在短期内会拖慢你的进度，但从长远来看会有很大的回报。

3. 优化代码审查过程

无论是等待审查、修复评论，还是获得批准，代码审查（CR）可能是一个重要的时间浪费者。然而，在这里实施微小的改进可能会产生巨大的效果。

为了更好地理解如何改进CR过程，让我们把它分解成各种元素。

代码审查时间 = 首次审查时间 + 批准时间 + 合并时间

第一次审查的时间

首次审查时间表示从一个人打开一个拉动请求（PR）到第一个人审查它需要多长时间。

虽然你不希望人们在每次有新的PR时都放下一切，跳入审查模式，但第一次审查的时间长意味着作者方面有更多的多任务。

健康的初审时间应该是几小时，而不是几天。

在我的团队中，一个行之有效的策略是在一天中创造两到三个代码审查时间段。我要求团队至少在一天的开始和午休之后检查版本库并处理任何代码审查过程。

• PR中的评论数量
• 解决评论的时间
• 需要批准的数量

在团队刚上手并学习如何共同编码时，评论的数量通常很高，但随着时间的推移，评论的数量应该最小化。请求的大小是这里最重要的因素。如果一个PR中有50条评论，这可能是一个不健康的大PR。

解决评论的时间显示了团队在一个特定的PR上的工作强度。再说一次，你不希望人们因为有一个开放的PR而放弃一切，但关闭正在进行的PR应该比创建新的拉动请求更优先。

需要批准的数量既影响代码审查时间，也影响其时间消耗。虽然没有银弹，但你应该确保这个数字与你的目标相关。

如果你正在推出一个MVP，四个批准可能是一个过度。如果你是一个成熟的团队，最近有很多年轻人加入，一个批准可能不足以维持代码质量。

合并的时间

合并时间告诉我们从最后一次批准到合并代码和关闭拉动请求需要多少时间。理想情况下，它应该接近于零。

一个健康的CI/CD管线应该为团队处理这个问题。

4. 优化质量保障流程

专注于使你的测试过程尽可能快，同时保持高质量标准。其中一些策略包括:

左移测试

测试不应该是过程中的最后一步。你越晚发现问题，解决起来就越费时。你越早聘请QA专家越好。

在开始开发之前，让QA专家审查规格和设计，可能会给你带来很多麻烦。

建立质量文化

虽然QA工程师是团队中的质量专家，但这并不意味着只有他们负责增量质量。为整个团队实施质量保证过程。

工程师在把工作交给QA专家之前，应该对他们的工作进行反复检查和自我测试。否则，发现后期错误的机会就会大大增加。

5. 发现并调查异常值

所有工作项目都有相同的周期时间，这是很不可能的。要注意异常值，特别是那些明显长于周期时间中位数的工作。

调查这些异常值，发现他们为什么花了这么长时间。这些异常值是否太大？是CR或QA花了太长时间吗？是由于技术债务的问题吗？然后专注于解决这些问题。

通过彻底审查异常值，你可以了解很多关于你的流程效率。

6. 减少技术债务

我将技术债务视为卓越技术状态与当前状态之间的差距。它可以是疏忽造成的，也可以是有意识的权衡。这方面的例子包括。

• 我们决定现在不修复的错误
• 缺少的文档
• 低效的持续交付工作流程
• 缺少测试自动化
• 折旧的库和框架
• 未使用和混乱的面条状代码
• 次优的基础设施
• 削减了UI和UX的实施

从长远来看，技术债务水平越高，周期越长。

我喜欢的一个策略是定期讨论技术债务（例如，每月的风险评估会议）。

有关于采取和报告债务的准则也是有益的。

例如，每当我们走捷径或注意到差距时，我就要求团队报告一个特殊的技术债务票据，并规定技术债务票据的总积压量不能超过平均冲刺速度的200%（这个数字因情况而异）。

虽然对于多少技术债务是可以接受的并没有完美的答案，但有意识地监控和管理技术债务水平是至关重要的。高水平的债务会大大降低你的速度。

7. 用较小的碎片工作

确保你的工作项目在可行范围内尽可能小。任务越大，需要的时间就越长，带来的过程和产品风险就越大。

虽然不是每一个PBI都能被分割成更小的项目，但大部分都可以。

我最喜欢的减少项目规模的策略是慢慢地给每张票的故事点的最大数量设限。

比如说，如果我的团队的大部分票据是1、2、3、5、8、13和21个故事点，那么第一步的目标就是在进一步的冲刺中消除21个故事点的票据。然后，只要我们有21个故事点的票据，我们就会尽一切努力将其分解。

一旦我们掌握了它，我们就把重点转向13个故事点的票据，以此类推，直到我们对工作项目的规模感到满意。

试一试吧。这往往比听起来更容易。

8. 运行实验

周期时间是一个关键的指标，值得以类似于实验产品的方式进行实验。

仔细研究，设定假设，计划实验，看看指标如何变化。结果可能会让你吃惊。

例如，我和团队一起做了一个实验，实施一个slack机器人提醒，每天追赶两次PR。

实验结束后，团队说他们对机器人的不断提醒感到厌烦，建议我们把它关掉。但是，当他们看到自从实施机器人后，我们的总CR时间下降了大约40%，他们改变了看法。

小的变化可以产生令人惊讶的结果，所以要继续试验并测量结果。

翻译：云瑞设计