对产品精益求精

精益产品需求的要义

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

1.需求的新定义

这里所说的“需求”是指计算机技术诞生以来的“软件需求”，可以稍微追溯一下历史。下图是迈克尔·波特的《IT变革的三次变革》[1]。作者的本意是看技术在变化的时代中的作用和地位，但这里我们将看IT需求的变化特征。

图1迈克尔·波特信息技术发展的三个阶段

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

我想大家都深刻感受到了这个突出的变化，就是总体来说，市场需求的不确定性越来越高，竞争越来越激烈。

同时，如果对比软件开发方法的发展，似乎有三个对应的时代:

图2软件开发方法的演变和需求定义的推导

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

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

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

2.需求问题的多重挑战

以下是我们收集到的一些常见需求。看起来眼熟吗？

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

如果您仔细分析这些问题，本质上可以归结为以下挑战:

图4需求的多重挑战

挑战之一

需求上升时的“不确定性”。产品需求的本质变成了一种“有价值的假设”，而不是传统意义上的确定，从一开始就被准确定义。“市场用户需要一匹更快且永不疲倦的马”是一个“有价值的假设”；“用户需要车”是不断转和学习的结果。人善于解决确定性问题，面对不确定性时，往往会手足无措。产品创新连接了业务、技术和人，但是方向太多了。应该从哪一点入手？当你第一次想出一个产品创意时，如何找出“比竞争对手更可靠的假设”？这是一个前所未有的挑战。

挑战之二

需求层层分解后，可能会完全失去初衷。即使在开始的时候，我们已经确定了更接近“正确结果”的假设，但是在实现的时候，由于组织分工、政治、规划等约束，必然会被拆解成零件，然后一个一个实现，组装之后再进行验证。在这个过程中，拆装的结果很可能会让初衷无法实现。

挑战之三

实现需求所必需的社会合作导致了需求的扭曲或“污染”。需求的交付是一个社会化和协作的过程。所有参与的人都有不同的背景、知识、能力、起点和兴趣。当他们理解、表达、传输、接收、消化和再传播需求时，他们将“解释和过滤”这些需求。这种协作过程的产品很可能会扭曲需求或者被“污染”成另一种样子。

挑战之四

需求的及时性。在验证假设的过程中，外部市场是不断变化的。可能即将在网上验证。突然，市场上诞生了另一个产品horizontal空，消费者行为发生了变化。“原来的选项不再是选项”。

3.这么多挑战，有解吗

如果我们认识到需求只是一组假设，那么我们将:

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

如果我们认识到需求的分解会导致需求扭曲，那么我们就会:

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

如果我们认识到需求的社会协作(沟通、传递、协调)会导致需求的变形，那么我们将:

统一需求接口，减少沟通节点；按照产品职责来设置团队，让市场、技术和消费者直接沟通，减少中间环节；建立跨职能团队，避免部门政治给需求带来的污染；采用更直接、更简洁、更高效的方式去沟通，减少信息失真；

如果我们意识到需求具有时效性，那么我们将:

需求目标定得尽可能小，因为目标越大、验证学习周期就会越长，失效的可能性更大；时刻关注市场变化，随时做好调整转向准备

因此，应对需求挑战不仅仅是IT团队对个人和团队负责的事情，更是各个层面的思想文化、组织架构、管理流程、领域洞察、沟通协作能力等多个维度的事情。

4.精益产品需求是什么

目前，在很多已经开始尝试或者已经实施敏捷转型的企业中，团队层面的“敏捷开发方法”应用最为广泛。如果将与需求相关的方法和实践进行浓缩，大概会是下图这样:

图5目前常用的“敏捷需求分析”

回过头来看，我们会发现图中的这些方法、实践和工具主要是改善了IT交付团队内部的“需求的沟通和传递”，通过“小步发布”略微改善了“及时性”问题，其他问题似乎变化不大。所以有这样一个问题:“实施敏捷需求分析的效果，就是团队内部的合作和沟通更加顺畅，对业务没有影响？”

如果要完全应对这些需求挑战，就需要应用“精益企业”的指导方法[4]——将敏捷和精益思维应用到与需求相关的所有维度和层面，如组织结构、管理流程、领域洞察、沟通协作能力等。

此外，“传统上，大多数企业都在坚持以范围、成本和进度为中心的交付管理，这使得所有人都迷失了方向。似乎项目交付才是目的，而忽略了投资的初衷本身就是为了达到的用户和商业目标，更不要说持续创新了。现代科技企业面临的竞争环境越来越激烈，用户和市场瞬息万变。要能够快速适应变化，真正创造出用户喜欢的有竞争力的产品，并保持创新，就必须告别过去多年“以项目为中心”的管理，建立以产品为中心的软件交付模式”[5]。要按照面向业务的能力来组建产品团队，从产品的全生命周期——机会发现、定义、推出、成长、成熟、进化来看待和管理需求。

如果我们尝试定义“精益产品需求”，那就是以“精益企业”为导向，以产品为中心，将敏捷和精益理念应用于与整个产品生命周期相关的组织结构、管理流程、需求沟通和协作的方法和实践。

结合第2部分中的常见需求挑战，无非是在组织级别应用精益思想和原则:

精益产品要求的目标:

通过在组织、团队、个人层面的精益需求发现、管理、沟通和协作实践，来提升组织的响应力和创新力。

“精益产品需求”的原则:

对业务领域、市场、用户需要有洞见，来主动驱动业务变化，而不是仅仅理解跟随业务变化；真正以客户/用户为中心，像客户/用户一样思考，由客户/用户价值来驱动决策，而不是利用组织政治来决策；共同一致的需求愿景和目标，高度透明、可视化、协同地、高质量地需求沟通，而不是不写文档、频繁但低效地沟通；去中心化的产品体系架构和产品团队，负责产品的整个生命周期，而不是项目团队，只注重交付的速率不注重交付的价值；以业务成效来度量和验证价值，形成价值闭环，而不是单单衡量IT团队的交付效率和产能；产品的需求，少就是多(LessisMore),做减法；

图6精益产品需求的价值闭环

“精益产品需求”方法:

产品化方法，区分探索期和拓展期的工作方法

不同产品生命周期的关键方法：

图7产品生命周期和关键方法

“精益产品需求”的实践和工具；

图8精益产品需求的实践和工具的例子

以某大型外资金融企业为例。他们实施了“以客户为中心”的组织结构调整，并实施了五年的敏捷转型。他们想借这次重组实现“精益产品化治理”，解决“业务需求响应慢”的问题。他们面临的具体挑战是:

经过了几十年的运营，IT系统非常复杂，仅客户平台这块新老系统超过200个，相互紧耦合。以项目团队进行工作，项目之间相互依赖，经常出现因为等待依赖而浪费大量的时间；项目启动基本上是瀑布方式，概念阶段和启动阶段长达数月；开发和运维分开，负责维护的团队觉得不被重视，长期士气低落；

它们的改进路线和应用实践如下:

图9XX金融企业需求改善路线

应用实践:

“以面向业务的能力来构建产品团队”，每个产品团队自己规划自己的项目，以持续交付、持续验证的方式来演进自己的“能力”（如发展新产品，退役旧产品）；每个产品团队设立ProductOwner和ProductArchitect，按照“业务能力职责”，共同规划自己产品体系的发展蓝图及运维支持；持续的产品需求技能提升训练和实践社区；产品团队建立后，运维放到产品团队做了之后，发现总体人员规模可以减少1/5–目前这1/5的人用来识别创新机会，在团队内开展创新项目。5.写在最后

很多企业在面对图4所列的需求问题时，首先想到的是组织需求分析师的技能培训，为他们制定一个工作流程，给他们发一本“进阶实践”的手册，然后期待这些需求问题得到解决。但是这样过了一年，好像什么都没有改变，那些存在的问题依然存在。

希望通过这篇文章让大家认识到，在新的数字经济时代，需求的不确定性更强，挑战来自于外部市场，内部的组织架构和管理，能力等各个方面。企业在实施转型或改进时，可以从更系统的角度来看待，真正实现“精益产品化治理”。

另一方面，从个人和团队的角度来看，图5所示的“敏捷需求分析”的方法和实践仍然适用，但是应该有两个关键的变化:

一是“产品思维”，“人人都是产品经理”，认识负责产品的生命期，根据不同的生命期取舍不同的需求实践，全面掌握不同生命期的实践方法；二是“精益思维”，以业务成效来度量，对需求要有效做减法。参考资料：

[1]:迈克尔·波特，http://www.FAZ-forum.com/SCP/150121_SCP_Porter_Harvard_heppelMann_PTC.pdf。

[2]:“敏捷方法集群”是指以Scrum、XP等为代表的轻量级迭代开发方法。

[3]:小然，《从敏捷到精益企业》，http://insights.thoughtworkers.org/From-Agile-transformation-to-Lean-Enterprise

[4]:“精益企业”。[5]:姚安峰《精益企业的原则:关注产品而不是交付项目》，http://www.infoq.com/cn/articles/the-principles-of-Lean-Enterprise-以产品为中心。

作者:康ThoughtWorks首席商业分析师、顾问，中国区行业研究团队负责人，负责金融(银行、保险)企业数字化转型研究，精益产品创新方法咨询。

作者@康未经允许禁止转载。康江美

注:阅读相关建站技巧请移至建站教程频道。

欢迎分享，转载请注明来源：内存溢出

原文地址: https://outofmemory.cn/zz/769011.html