非项目——产出物：改变的价值

这是#非项目系列文件中的最后一篇；研究了组织如何以非项目的组织形式来进行持续交付。如果你还没有准备好，请先阅读一下该系列的前两篇文件：第一篇和第二篇。这一篇文章依赖于之前讨论的概念和基于工作量和价值来可视化和管理不断改变的流程的方法。
我们本文将改变一下语境——产出物。详细讨论如何定义产出物、它们相互作用的管理和成功标准的度量是务实的做法。我们将以一个警告作为本篇文章的结尾：浮现出隐性项目的风险。也就是说，模仿项目组织方式的工作模式，只是名称上不同罢了。

什么是产出物？

从根本上说，所有项目的目标都是创建新的组织能力，无外乎技术性或功能性这两种。那么问题来了，组织可以不以项目驱动的方式来引入新的能力吗？
简而言之，可以。关键是把能力作为具有价值的东西和产出物来思考。
无论从团队、部门或组织哪个层面来看，活动的连续流转都是更加关注产出物（outcomes）而非输出（outputs）。产出物是通过它为组织带来的价值来度量的，无论这个价值是直接且有形的，还是间接且无形的。产出物是有计划的、慢慢变化的，为组织定义了共同的方向。

然而，产出物可能会更为复杂，互相间会有依赖，偶尔还会有冲突。为了有效地管理以上种种，我们需要先来理解四件事：

1. 产出物的概要，
2. 工作原则，
3. 产出物之间的关系，
4. 以及非预期的结果

产出物的概要

产出物的概要为团队、部门或组织定义了环境、目的和预期。虽然组织间的概要会有所不同，但最起码都会包含以下内容：

1. 总结——产出物的简短描述。
2. 度量基准——如果产出物是可量化的，那么它目前是什么状态呢？
3. 拥有者——谁（个人或团队）对该产出物负责？
4. 依赖性和顺序（排列）——与其他产出物有关的产出物在什么位置？
5. 投入——完成该产出物的最大投入产出比是什么？
6. 当前目标——你试图要完成什么？尽量避免用百分比（它们很容易被运作），并记住这是当前的目标。它会随着时间的推移而产生变化。依赖于该产出物所在的环境，当前目标可能还会有一个时间期限或者到期日期。
7. 产出物测试计划——当针对该产出物目标采取行动时，你将如何来度量这些活动的有效性？

计划是不包含在概要里的。团队可以期望通过调查不断的变化而去动态反应以抓住市场或组织内的机遇。

产出物概要示例

工作原则

为了长远的有效性，产出物需要受到约束。我们不能让部门和团队做任何他们不想检查的事，与此同时也不能束缚他们的交付能力。为此我们创建了一套分级的原则，这些规则与产出物无关，可适用于所有的活动。我们很期望每个团队能根据自己的重要性创建自己的原则。原则可以在质量、沟通、职工管理、安全性、品牌化等领域或其他任何共公领域来约束团队。

要意识到，每个原则会增加每项活动的成本和工作量。出于这个原因，原则应予以分级。你可以使用任何划分优先级模型，但我一般会推荐 MoSCoW。

• M - 必须有：没有商量余地的原则，要想完成就必须要遵守它，无一例外。例如：所有活动必须在编码之前就已经写完相关的自动化单元测试（TDD）。
• S - 应该有：团队需要遵守这些原则或证明它们是不适用的。例如：所有认证应该直接连接到公司的活动目录系统。
• C - 可以有：可选的原则，可作为一个指导原则，由团队自己来决定。例如：可以针对每个活动来写 OWASP 安全性测试并作为回归测试套件的一部分来执行。
• W - 不要有：团队应该避免的反原则。

产出物之间的关系

各级组织的产出物有着天生的粒度。组织级产出物通常粒度较粗，关注的是收入、职工和产品。
部门级产出物通常会分解单独的组织级产出物。分解的目的是在组织内专注于该产出物，并明确其所有权。高管将对此负责，比如 CIO。

在团队级，产出物会非常具体，并和部门级产出物相关。然而，如果组织级结构本身就很复杂，那么团队级产出物可能还需要第二个父级产出物。不管它们之间有怎样的关系，必须有一个单独的团队或部门经理来负责。
例如（创业公司的产出物）：
组织级产出物：以每股的价格出售公司，同时保证部门级产出物：每季度来自于订阅的收入增加到 X。
团队产出物：免费到交付的转化率增加到 2%

意外结果

这个工作模型的最大风险是由于产出物的冲突导致的意外结果。当部门或团队间缺乏交流沟通时，没讲清楚要描述的产出物时，不同产出物之间有优先级的冲突时或发展 / 变化和稳定 / 现状之间天生的对立关系时，都会造成产出物的冲突。

对于技术性团队而言（这是这一系列文件的背景），可以用 4 种方式来缓和这些意外结果。

1. 公开可用的活动画布（Activity Canvas）：整个组织都可以看到每个团队的活动画布时，团队就可以确认其他活动是否对它们有消极的影响了。这需要团队积极地检查与团队密切相关的活动画布。不过，一定要谨记一点，使可能会导致消极影响的任何变化都更加清晰、透明。
2. 定期重组团队：让价值交付团队中的人定期流动一下，而不是仅仅分享一下技能和经验，使大家不再因为“我们”还是“他们”的角色定位而产生不同的行为举止。反过来说，这有助于促进协作的文化，在冲突发生之前就发现潜在的苗头。
3. 自动化的测试、回归测试和回滚：如果变更直接关系到技术环境，任何新做的和修改的功能都应该经过这三个系统的检查。
4. 自动化的测试系统 - 检查它是否在按预期运行
5. 自动化的回归测试系统 - 验证它没有破坏其他的功能，以及
6. 自动化的回滚系统 - 如果变更的地方有之前两步未发现的问题，则撤消。
7. 工作原则：最后，每个活动的识别和提出都需要遵守既定的工作原则。这会保证从长远来看那些会带来短期收益的变更不会带来大的问题。

把它们组合到一起

不把团队与特定的输出绑定，对产出物的增长有深刻理解（并为此做计划）的组织能从根本上使自己适应市场的变化。管理控制以公共的工作原则和清晰定义的、无冲突的产出物来发挥作用。高级管理者可以委派价值交付团队去决定“如何做（how）”，同时保留“做什么（what）”和“为什么做（why）”的决定权。

团队组织

简单说一下团队组织。在前面文章中讨论过，价值交付团队不是围绕职能筒仓（可能组织的剩余部分仍存在这种情况）建立的，而应该为满足产出物的要求由适当的技能和角色混合而成的。不要把它错误地理解为矩阵组织中的项目团队。理想情况下，这是一个向负责该产出物的一线经理汇报的执行团队（或部分）。

noprojects 的所有要点是，价值交付团队将为努力完成目标产出物而做出改变。

产出物的度量

因为每个活动都很小，所以对产出物的影响可能也很小甚至可以忽略不计。我们感兴趣的是所有活动对产出物的累积影响。如果产出物是团队可量化的，那么就每隔一段时间针对基准来度量它们的进展。度量的形式取决于产出物以及它的量化方式。团队也可以根据结果在收益概要内设定新的目标，或者彻底变更产出物。组织可以使用这些度量值做出明智的决定，以指导下一步的投资和战略方向。

特殊情况——A/B 测试和持续度量

在很多情况下产出物都很普通，可以直接通过度量来预测（比如维持运行的稳定性和安全性）。如果一些活动对产出物有不清晰 / 不确定的影响，那么我们建议使用 A/B 测试，并在可能的时候予以度量。

“顾名思义，A 和 B 是两个可对比的版本，它们除了一处会影响用户行为的地方不同之外，其他地方完全相同。版本 A 可以是当前使用的版本（控制），而版本 B 是做过修改的。例如，电子商务网站上的购买漏斗就很适合用 A/B 测试，即便是稍微改善下降率也能代表销售方面的有显著提升。”——维基百科

度量一个活动的价值

每个对产出物负全责或部分负责的价值交付团队将识别和从事一项特定的活动，阅读之前的文章“关注价值，非项目”（ http://www.infoq.com/articles/ ）了解更多的细节内容。每个活动的目的是在该产出物所在的环境中直接或间接产生价值。而你需要在此考虑 5 个方面。

1. 价值的衰减。这实际是#非项目的所有要点。如果你不能紧跟变化，那就已经失败了。价值是通过任何活动产生的，一旦实现了，就会开始衰减。衰减的程度依赖于具体的环境，但遗憾的是衰减是必然会发生的。
2. 价值会随时间衰减 你不会总是先进行最具价值的活动。活动间是有依赖关系的，而且已经临近到期日期的活动的优先级可能也会比高价值的活动更高。

3. 已发生的成本和已创建的价值的趋势对比 局部最大化。如果你发现你的活动未对产出物产生预期的改进，有时就需要削减该产出物的总体商业价值以便将来增强了。例如，为了简化将来的开发而去削减一个产品的功能。当你已经达到了收益递减点或变更（或创新）的成本呈指数增加时可能就会发生这种情况。

4. 价值随时间推移呈现局部最大化 活动失败。并非所有的活动都将对产出物产生积极的影响，有些可能会没有作用甚至会有负面作用。这也正是为什么活动要小、要独立并可以合在一起来度量。
5. “又会如何”要素。在增加任何活动到活动矩阵之前先问问自己“如果不这样做，又会如何？” 产出物是那些专注于为组织创建价值的活动的衡量标准。理解这一点了，在采用#非项目之路上就已经成功了一半了。

隐性项目

与流程或技术变革相比，#非项目更多的是文化和行为上的变化，尤其明显的是隐性项目的出现。隐性项目是在#非项目或持续变更的环境中出现的一种模式，它实际上模拟了项目的结构，只是没有正确命名罢了。

识别组织中的隐性项目，它对于理解项目的特征来说极为重要。与我们息息相关的是项目天然的临时性、约束性和独立性。

临时性

从定义来看，项目是为实现一个特定变化或一系列变化的临时性组织结构。这完全背离了#非项目的原则，#非项目发扬的是持续变化的模型，价值在于不断地开发新的能力。当为生产单个输出（可能会被称为产出物）而形成团队并定期转向到不同的输出 / 产出物时，可能就会出现隐性项目了。如果团队是分散的，并且可能会为了在最后时期重新再处理产出物而重组时，情况会更为复杂。

你要小心，别把这一点和最终不会产生预期结果的商业实验给搞混了。同样，别把它和投入产出比已经开始下降的产出物的生命末期给搞混了。

耗费的成本与创造的价值随时间推移的趋势对比

约束性

在商业中，约束极其重要，在#非项目中更加重要。然而隐性项目会给团队施加人为的限制，通常是限定时间、成本或范围。如果你的管理者在特定的时间内要求一个特定的产品或预定义的活动，那它其实就是个项目。
记住，虽然个人活动也可以有到期时间，但是这些约束和固定的范围或既定的目标有着本质上的不同。

筒仓

职责筒仓间必然会有问责制、发起和移交。因为项目是一种临时的结构，所以项目团队的一线管理者往往和项目经理会有所不同。这会导致多重审批、责任移交和无效的矩阵结构。
当管理间或职能领域之间有隐性的（或类似的）审批流程时就会出现隐性的项目了。无论是价值交付团队还是职能等级的结构，#非项目都需要有一个对所有可交付活动负责的点。换句话说，团队的一线管理者和特定产出物的“赞助者”应该是同一个人。

最后的思考

从根本上说，如果管理者和职工未抱着#非项目的心态，那么隐性项目就会开始出现了。最好的情况是试图坚持到最后以维持目前的现状，最坏的情况是他们阴险地想要推翻#非项目最初的目的和目标。
只要你记得这些反模式，就可以在它们影响到你之前发现和解决掉它们。

关于作者

Evan Leybourn开拓了敏捷商业管理的领域，把精益和敏捷运动中的成功理念和实践应用到了公司管理中。他忙忙碌碌地做着业务带头人、顾问、非执行董事、会议发言人、有国际影响力的作者和父亲。Evan 对构建有效而高效的组织有着浓厚的兴趣，致力于让组织充满积极参与和注重承诺的人。他认为只有这样组织才能繁荣发展。他曾经担任过私企和政府的领导和董事会的职位，这些经历促进了他在商业系统方面的工作，在本地和国际产业研讨会上他也会定期演讲这些主题。Evan 不仅编写了《敏捷组织指导》，目前还在帮助 IBM 新加坡，希望他们成为前沿的敏捷组织。像往常一样，所有思想、理念和评论都是他的个人观点，不代表他的客户或员工。

查看英文原文： #noprojects - Outcomes: The Value of Change