如果您还没有阅读 资源效率与流程效率，第 1 部分：查看系统 ，我在那里解释了针对给定人员的工作进行优化与针对功能进行优化。一些刚接触敏捷的人（包括经理）对在流程中工作与为一个人进行优化有疑问。
管理人员问：
- 如果我们转向流程效率，我怎么知道工作不会花费更长的时间？
- 如果一个人不对他/她的工作负责（什么是问责制等），我该如何进行绩效管理？
这篇文章是关于工作的长度以及人们无法完成工作时的感受。
当你有专家时，就像资源效率一样，工作排在专家后面。假设您有三位资深人士，他们分别拥有这些不同的专业领域：
- Cindy 对数据库的内部结构以及如何使事情变得更快（我认为这是平台）有着深入的了解。
- Brian 对事务层以及如何在产品中将数据从一个地方移动到另一个地方（我认为这是中间件）有深入的了解。
- Abe 对如何向客户呈现数据以及如何创造出色的客户体验（我认为这是 UI 层）有着深入的了解。
您需要具有显着 UI 影响的功能 1 和 2。 Abe 擅长与所有必要的人员进行迭代，以使 UI 恰到好处。同时，Cindy 和 Brian 继续学习功能 3、4 和 5，因为功能 1 和 2（目前）不需要它们。
如果您测量累积流量，您会看到所有五个功能都打开了一段时间，因为这三个人已经开始使用它们，但还没有完成任何事情。
Abe 遇到了 UI 问题。客户没有回应或产品管理人员不在。有些东西阻碍了他的进步。因此，他启动了功能 9，这是具有重要 UI 设计的下一个功能。
请注意，他没有开始下一个排名功能。他开始下一个 他 可以工作的。
Cindy 和 Brian 也遇到了延迟，因为测试自动化不存在，或者构建花费的时间太长（或其他原因）。选择上周发生在你身上的任何事情作为障碍。
他们需要保持忙碌，所以他们看到 Feature 6 需要他们两个。他们开始了。他们意识到需要进行 UI 工作。他们问安倍他是否有空。不，Abe 正在处理功能 9，而不是功能 6。现在，Cindy 和 Brian 正在处理另一个功能。
如果这听起来像您的项目，那么您并不孤单。这是资源效率的结果。
资源效率对人类的影响是多任务处理，一种迫在眉睫的压力感，因为你可以看到最后期限，但你并没有越来越近。你想知道你是否会完成这项工作。
相反，想象一下，如果 Cindy、Brian 和 Abe 与测试人员一起使用功能 1。他们可能会准备工作的平台和中间件部分。他们可能会帮助 Brian 进行原型生成和迭代。如果安倍需要专注于特定的事情，他们可能会敲门。 “我会在几个小时内完成这件事。能不能预定个会议室，让产品经理去？她总是在用户界面上给我带来困难。我想知道她现在是怎么想的。”或者，“你能打电话给客户 A 并准备好在几个小时内进行演练吗？”
您可能会认为这种预订房间或打电话给人们的工作是项目经理 应该 做的事情。实际上，这些行为是仆人式领导行为。任何人都可以做到。
对于开发的某些部分，我们通常有提前期。即使我们想在流程中工作，我们也可能需要其他人来完成。
即使 Cindy 和 Brian 不能直接帮助 UI，他们也可以让 Abe 更容易获得成功。而且，如果测试人员一开始就参与进来，测试人员可以创建不依赖于 GUI 的自动化测试。也许不处理产品代码的开发人员可以帮助使用自动化测试框架。 （我发现刚接触数据驱动或自动化测试的测试人员并不总是知道如何开始。开发人员可能会提供帮助。）
想象一下，如果 Cindy、Brian 和 Abe 不是他们团队中的唯一成员。他们是最资深的，团队中还有两三个其他开发人员。当那些初级开发人员有问题时会发生什么？ Cindy、Abe 和 Brian 不得不停止编写他们的故事以与其他人合作。或者，也许他们不这样做，而其他人被困住了。我一直在团队中看到这一点。我敢打赌你也是。
当我们优化资源效率时，我们会有未完成的开放工作的人。他们没有完成的工作越多，他们后面等待的新工作就越多。他们整天都在努力工作，却感觉自己没有完成任何事情，因为没有事情要做。
当我们优化流程效率时，人们会一起完成事情。他们正在进行的工作较少。他们感到有成就感，因为他们可以指出他们已经完成的事情。
我不能保证团队可以更快地完成流程，因为我不是学者。但是，您听说过“人多力量大”。就是这个主意。当我们互相帮助完成一大块工作时，我们都会更快地取得成功。
第 3 部分将讨论管理者对绩效管理的看法。