这是关于资源效率与流量效率的一系列帖子中的下一篇：
- 资源效率与流程效率，第 1 部分：了解您的系统
- 资源效率与流动效率，第 2 部分：对人的影响
- 资源效率与流程效率，第 3 部分：管理绩效
刚接触敏捷的经理经常问，“我怎么知道人们会负责？”让我们梳理一下问责制的各个部分：
- 对项目负责完成自己的工作
- 对他们的团队负责，通过他们的工作充分参与
- 负责通过记录他们的工作来帮助其他人了解他们所做的事情
- 负责满足他们的估计
- 对项目如何花钱负责
- ......可能会有更多的责任
让我们把前两个放在一起：
对完成自己的工作负责并通过做他们的工作
我怀疑管理者的意思是，“我怎么知道每个人都在做他们的工作？我怎么知道他们没有要求其他人完成他们的工作？我怎么知道这些人正在学习做自己的工作？”
这些都是很好的问题。我还没有看到单人功能。至少，开发人员需要有人来测试他们的工作。是的，可以测试您自己的工作。我敢打赌，你们中的一些人非常擅长这一点。许多人不是。如果您想防止返工，请以某种形式内置检查：配对、设计审查、代码审查、单元测试、系统测试等。
所以关于“自己的工作”的部分对我来说似乎有点微观管理。
关于做他们的工作的部分有点棘手。当人们陷入困境时，他们会怎么做？通常，他们会向其他人寻求帮助。帮助可能是：与鸭子交谈，解释产品该领域正在发生的事情，结对解决问题，甚至与更多人交谈。
工作中没有“作弊”这样的事情。经理们担心人们会发挥他们的能力是正确的。而且，如果那些人被困住了，我不希望他们陷入问题的泥潭。我们希望人们学习，而不是被困住。
答案是：作为经理，你无法知道。作为经理，你从来不知道。
团队知道谁勤奋，谁懈怠。团队知道人们的学习方式以及他们是否遇到困难。即使在瀑布时代，团队也知道。经理们可能有他们知道的错觉，但他们没有。经理们只知道人们告诉他们什么。
负责文档
对我来说，问题是谁将使用文档？我总是惊讶于有多少经理想要最终用户文档以外的文档，而有多少团队认为这有用。在敏捷中，您可以将其作为完成定义的一部分。
如果人们将文档时间纳入他们的估计，并且团队发现内部文档有用，则团队将迫使每个人交付他们的文档。团队知道此人是否记录了他们的工作。
对达到预期负责
当我问经理们他们是否想要好的估计或完成的功能时，他们几乎总是说“完成的功能”。人们经常在修复缺陷或生产支持工作时执行多项任务，而他们应该在功能上工作。我确实理解 估算 的必要性，但是让人们坚持他们的估算？有时候，这就是钱的问题。
对项目如何花钱负责
在所有责任中，这一项对我来说最有意义。然而，这在敏捷中没有意义，客户/产品所有者是负责人。只要团队完成功能，PO 就会确定积压工作中没有更多价值，或者项目没有更多资金。幸运的是，该团队此时已达到发布标准。
对我来说，问责制的想法是基于团队的想法，而不是基于个人的想法。在流程效率方面，你可以要求团队负责：
- 整理功能
- 了解他们在进行中的功能方面的位置
- 帮助 PO 了解功能的价值以及功能需要多长时间
- 如有必要，提供估计
- 如果团队在迭代中工作，致力于工作而不是过度投入太多工作
当你这样看待问责制时，它看起来与一个人的问责制有很大不同。
