精益产品需求的要义

在新的数字经济时代下，需求不确定性更强，挑战来自于市场外部、组织内部的结构和管理、能力等多个方面。在实施转型或改进时，企业能以一个更系统的视角来看待，真正实现“精益的产品化治理”。

1.需求的新定义

我们这里说的“需求“，是沿循计算机技术诞生以来的“软件需求”，所以可以稍稍先回溯一下历史。下图是Michael Porter的“IT变革的三次变革”[1]。作者的本意在于看待技术在时代变迁中扮演的角色和地位，我们这里则去看看IT需求的变化特点。

图1 Michael Porter IT发展的三个阶段

信息技术时代：IT主要是用于实现业务、流程自动化，期望利用技术来提高“效率”，相对而言，因为工业时代的业务流程相对固化、计算机技术资源能力的相对稀少，商业市场对软件的需求变化并没有那么大；Internet时代：互联网变成新的营销渠道，市场对技术的期望不单是自动化固有流程，而是延展业务，所以外部需求的不确定性、变化越来越多；同时也因为技术渗透更广，软件服务的竞争程度也更加激烈；数字时代：技术渗透到生活方方面面，引领着消费、生活、商业生态的革新，市场变化日新月异，高度竞争，企业都在追求创新，市场对企业的期望是“高响应力“，甚至是引领力。需求变得更加易变、不确定。

我想大家都深切感受到了这个突出的变化，那就是：普遍来讲，市场需求不确定性越来越高，竞争越来越激烈。

与此同时，如果对比软件开发方法的发展，好像也对应有三个时代：

图2 软件开发方法的沿革和需求定义的演绎

软件工程时代：对应于上图的“信息技术时代”。市场需求聚焦在现有业务流程的自动化，大工业时代固化下的业务流程并不会天天变，所以对需求的定义是“软件功能的规范说明”。工作方式是瀑布式的：先花大量的时间模型化业务流程，制作出详细的“需求规格说明”，然后才进行开发实现。敏捷转型时代：对应于上图的“互联网时代”。随着互联网的出现，信息技术不再是自动化固有流程，而开始延展业务，如进行网上展示、销售和营销。这时，发现需求的不确定性变大了，用传统的“瀑布”方法不能适应外部市场的需求变化，软件项目失败率非常高，于是开始寻找更轻量的、迭代试错、小步前进的轻量级敏捷方法，来提升软件团队的响应力。这时，对需求的定义也演绎为“代表着业务价值的一个单元”。但是，这种变化始于IT也仅限于IT，敏捷方法簇[^2]里需求相关的实践和方法大多是面向技术团队的，如小步发布（Small Release），产品负责人(Product Owner)要和技术团队在一起，来制定团队的迭代计划、排优先级、澄清需求问题等等。虽然开始关注业务价值，但却仍主要度量IT团队的效率和产能。精益企业时代：对应于上图的“数字经济时代”。面对高度不确定、激烈竞争的市场，发现需求和定义需求的过程，变成一个不断试错、然后逼近“正确结果”的过程，这已慢慢成为大家的共识；同时，面对市场的高响应力、引领力的要求，对需求的验证环路必然要穿越IT、销售、运营、市场等所有职能部门，才能形成端到端的闭环，持续创造市场价值，即“整个组织的更广阔精益变革”[^3]。

因此上，在当前高度不确定性的市场环境下，有必要重新定义下“需求是”：

需求是“建立在商业、技术和人之间的一组动态的、待验证的假设”；挖掘和定义需求的过程，是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。

2. 需求问题的多重挑战

下面是我们收集到的一些常见的需求问题。看起来是不是很眼熟？

图3 组织中常见的需求问题

如果仔细去分析这些问题，本质上会归结为下面的挑战：

图4 需求的多重挑战

挑战之一

需求产生时的“不确定性”。产品需求的本质都变成了“有价值的假说”，而不是传统意义上是确定的、一开始就能准确定义出来的。“市场用户需要一匹更快、永不疲倦的马”，是一个“有价值的假说”；“用户需要汽车”则是不断转向、学习的结果。人们善于解决确定性的问题，在面对不确定性的时候，往往束手无策。产品创新连接商业、技术和人，但方向有那么多，该从哪个点开始？如何在首次提出产品想法时，就能(比竞争对手）找出“更靠谱的假设”？这是前所有未有的挑战。

挑战之二

需求经过层层分解可能完全失去原有意图。即使在最开始，我们独具慧眼，已经识别出更接近“正确结果”的假设，但在落地实现时，因为组织分工、政治、计划等约束，不可避免地会被拆解成零部件，然后再一一实现，组装完了再去验证。在这个过程中，拆解、组装之后的结果很可能让原始的意图面目全非。

挑战之三

需求实现所必须的社会化协作导致的需求失真、或被“污染”。需求的交付是一个社会化协作的过程，所有参与其中的人背景、知识、能力、出发点、利益不同，在理解、表达、传递、接收、消化、再传播需求时，都会“解释过滤“一遍，这样的协作过程的产物极有可能让需求意图失真、或被“污染”成另外的样子。

挑战之四

需求的时效性。在验证假设的过程中，外部市场时刻发生着变化。可能就要上线验证了，市场上突然来了一个其他的产品横空出世，消费者行为因此而改变，“原有的可选项不再是可选项”。

3. 这么多挑战，有解吗

如果我们认识到，需求只是一组假设，那么我们就会：

转变思维——我们的所有工作过程，不再是一个对确定问题求解的线性过程，而是一个构建（Build）- 度量（Measure）- 学习（Learn）的螺旋前进过程，我们会认为“不确定”是常态，积极主动地调整计划以适应变化；步子迈得更小一点——每次定的“需求目标和范围”会更小一点，这样尽可能让错误的弯路更短一些，验证的成本也更低一些；尽量缩减验证、反馈周期——因为这样试错成本更低，所以我们就要拼命靠近客户和用户，与他们对话，花精力研究他们、了解他们；迫切想知道验证结果——所以在在产生需求想法时，就确定好度量指标和验证方法；为了一开始找到更接近的假设，我们需要对用户、领域问题、行业生态有更为深刻的洞察；

如果我们认识到，需求层层分解会导致需求变形，那么我们就会：

需求目标定小一点，尽量避免不必要的分解；简化组织结构，层级少一点，减少层层分解；建立跨职能部门，减少分解；

编辑：未知