需求工程：独轮手推车和需求有哪些共同点......
集成需求工程：将需求管理与验证相结合
阅读 Lifecycle Insights 电子书“产品开发困境：助力产品开发领导者满足产品需求和如期交付的 5 种策略”。
攻读本科（工程）学位期间，我在 GE 的设计工程部门实习了一段时间。和大多数企业一样，新员工在入职第一天要接受入职培训。培训材料介绍了 GE 的历史沿革，其中包含不少关于 GE 创始人托马斯·爱迪生的经典故事，例如“经过成千上万次失败的试验才制造出一个能用的灯泡”、“我没有失败，而是找到了 10,000 种行不通的方法”、“天才是 1% 的灵感加 99% 的汗水”，以及大家耳熟能详的其他故事。书的背面是当地 GE 的历史沿革，其中包含一个建厂时的故事......
故事讲的是一个工人每天推着装满泥土的独轮手推车离开建筑工地。在出口处，安保人员停下来在泥土中搜寻那个工人想偷的东西，但一无所获，于是让他走了。就这样，那个工人每天都推着装满泥土的独轮手推车离开，直到施工的最后一天，安保人员放弃了搜寻，直接问那个工人偷的是什么，得到的回答是“独轮手推车”。
鉴于我们花在基于文本的需求和需求文档上的时间，很容易混淆需求内容与需求容器之间的关系。在拜访不同公司时，我试着通过询问工程师其产品是什么来评估上述混淆/成熟度。如果他们伸手拿起一叠纸，或给我看一份很大的 PDF 需求文档，我就知道他们关注的是独轮手推车（工具），而不是产品内容。
在我从事高科技行业期间，管理层意识到要做的工作比干活的人多，因而开始致力于提高每个人的工作效率，尤其是生命周期前端人员，因为这些人决定了下游所有其他人的需求（管理层意识到项目成功的关键第一步是确保需求正确）。管理层对这些前端人员的行为所花时间/精力进行了研究，以了解其中可改进的地方，并发现：
- 他们将 50% 的时间花在生成/维护文档上
- 他们将 25% 的时间花在各种文档、演示文稿等的不同位置重新输入相同信息上
- 他们将 30% 的时间花在将想法传达给其他人（经常是一次会议重复召开）上
- 他们将 14% 的时间花在 futzing（术语，意指试图正确打印文档）上
这些加起来超过 100%（因为这些人每周工作时间远远超过 40 小时）。
如果您看过迈克尔·哈默 (Michael Hammer) 和詹姆斯·钱皮 (James Champy) 合著的《再造企业》一书（约出版于 1993 年），就应记得价值映射流程，即采集业务流程，评估花在这些流程上的时间/精力，然后将评估结果与对客户的价值进行比较。如果您发现任何花了时间但不受客户重视的东西，这就是应从您的开发流程中剔除的对象。将再造价值原则应用于需求时，需求规范/文档必须对客户非常有价值（相对于我们投入其中的精力）；这些文档一旦打印出来即作废（相对于我们花在它们上的时间），除非我们分析发现没人会阅读它们；人们倾向于认为，如果文档被签署，项目肯定没任何问题，等等。那为什么我们要花这么多时间在价值如此可疑的东西上呢？
其中主要原因在于我们如何获得报酬、证明合规性、与客户互动等。
以独轮手推车来打个比方，如果我们可以专注于产品内容而不是容器，并开始管理根据需要配置和应用的单个需求，那会怎样？以前，我们可以显著提高前端生产力（即考虑等待批次填充浪费的精益概念；在这种情况下，整个文档将等待审查/批准，直至收集到所有需求），而现在，我们可以将需求与开发过程相关联来获得需求的主要价值，这样产品就可以不断满足需求。我们所说的集成需求……
集成需求的一个例子是将需求与其下游验证流程相关联（毕竟，好需求的特点之一即是“可验证的”）。
因此，想象一下这种流程所带来的生产效率提升......定义一个与测试用例相关的需求，这些测试用例将重用来验证是否符合该需求（测试用例也是单独管理，而不是测试文档）；将需求及其参数与项目计划相关联，这些计划将告诉我们需要为哪个里程碑验证哪些需求。通过收集证据并与需求相关联来监控测试/验证的执行（提供从需求到验证和证据的站点线）。经验/问题/转义被反馈到流程前端，我们在那使用现有项目作为下个周期的起点（收集其所有经验）。
您可能会觉得一下子咬掉这么多东西太费劲了，但一路走来还是有价值的……
例如，仅将测试用例与需求相关联就有价值，根据我们的经验，我们发现以下情况并不少见：
- 30% 的测试用例没有来源：没有验证需求，即蠕变测试；30% 不必要的测试
- 25% 的需求未经验证：没有与需求相关联的测试用例；没有测试正确的东西
离开“独轮手推车（工具）”说起来容易，但在文化上却很难，尤其是当客户希望我们交付文档时。好吧，我们会生成并向他们交付文档，但我们专注于配置/管理单个需求，以在许多不同的项目中重复使用它们，我们以精益方式考虑需求（单个需求被批准与反精益等待一堆需求在一个文档中被批准），且我们现在有了从单个需求到其去向、如何/何时被验证、其历史、理由、问题等下一轮的站点线，可以在每个周期重复使用/改进。
阅读 Lifecycle Insights 电子书“产品开发困境：助力产品开发领导者满足产品需求和如期交付的 5 种策略”。
阅读我们的博客文章，了解有关需求的更多信息。了解如何在云端使用 Teamcenter X 快速且经济高效地控制产品信息和流程（包括需求）。
