精益产品需求的要义｜TW洞见
今日洞见
文章作者/配图来自ThoughtWorks：亢江妹。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
1. 需求的新定义
我们这里说的“需求”，是沿循计算机技术诞生而来的“软件需求”，所以可以先稍稍回溯一下历史。下图是Michael Porter的“IT的三次变革”[^1]。
作者的本意在于看待技术在时代变迁中扮演的角色和地位，我们这里则去看看商业市场需求的变化特点。
信息技术时代：技术主要被用于实现业务、流程自动化。人们期望利用技术来提高“效率”，相对而言，因为工业时代的业务流程相对固化、掌握计算机技术资源的稀少，商业市场对软件的需求变化并没有那么大；
Internet时代：互联网变成新的营销渠道，市场对技术的期望不单是自动化固有流程，而是延展业务，所以外部需求的不确定性、变化越来越多；同时也因为技术渗透更广，软件服务的竞争程度也更加激烈；
数字时代：技术渗透到生活方方面面，引领着消费、生活、商业生态的革新，市场变化日新月异，高度竞争，企业都在追求创新，市场对企业的期望是“高响应力“，甚至是引领力。需求变得更加易变、不确定。
我想大家看到了这个突出的变化，那就是：普遍来讲，市场需求不确定性越来越高，竞争越来越激烈。
与此同时，如果对比软件开发方法的发展，好像也有对应的三个时代：
软件工程时代：对应于图1的“信息技术时代”。市场需求聚焦在现有业务流程的自动化，大工业时代固化下的业务流程并不会天天变，所以对需求的定义是“软件功能的规范说明”。工作方式是瀑布式的：先花大量的时间模型化业务流程，制作出详细的“需求规格说明”，然后才进行开发实现。
敏捷转型时代：对应于图1的“互联网时代”。随着互联网的出现，信息技术不再是自动化固有流程，而开始延展业务，如进行网上展示、销售和营销。这时，发现需求的不确定性变大了，用传统的“瀑布”方法不能适应外部市场的需求变化，软件项目失败率非常高，于是开始寻找更轻量的、迭代试错、小步前进的轻量级敏捷方法，来提升软件团队的响应力。这时，对需求的定义也演绎为“代表着业务价值的一个单元”。但是，这种变化始于IT也仅限于IT，敏捷方法簇[^2]里需求相关的实践和方法大多是面向技术团队的，如小步发布（Small Release），产品负责人(Product Owner)要和技术团队在一起，来制定团队的迭代计划、排优先级、澄清需求问题等等。虽然开始关注业务价值，但却仍主要度量IT团队的效率和产能。
精益企业时代：对应于图1的“数字经济时代”。面对高度不确定、激烈竞争的市场，发现需求和定义需求的过程，变成一个不断试错、然后逼近“正确结果”的过程，这已慢慢成为大家的共识；同时，面对市场的高响应力、引领力的要求，对需求的验证环路必然要穿越IT、销售、运营、市场等所有职能部门，才能形成端到端的闭环，持续创造市场价值，即“整个组织的更广阔精益变革”。
因此上，在当前高度不确定性的市场环境下，有必要重新定义下“需求”：
需求是“建立在商业、技术和人之间的一组动态的、待验证的假设”；挖掘和定义需求的过程，是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。
下面是我们在提供咨询时收集到的一些常见的需求问题。看起来是不是很眼熟？
如果仔细去分析这些问题，本质上会归结为下面的挑战：
挑战之一: 需求产生时的“不确定性”。
产品需求的本质都变成了“有价值的假说”，而不是传统意义上是确定的、一开始就能准确定义出来的。“市场用户需要一匹更快、永不疲倦的马”，是一个“有价值的假说”；“用户需要汽车”则是不断转向、学习的结果。人们善于解决确定性的问题，在面对不确定性的时候，往往束手无策。产品创新连接商业、技术和人，但方向有那么多，该从哪个点开始？如何在首次提出产品想法时，就能(比竞争对手）找出“更靠谱的假设”？这是前所有未有的挑战。
挑战之二: 需求经过层层分解可能完全失去原有意图。
即使在最开始，我们独具慧眼，已经识别出更接近“正确结果”的假设，但在落地实现时，因为组织分工、政治、计划等约束，不可避免地会被拆解成零部件，然后再一一实现，组装完了再去验证。在这个过程中，拆解、组装之后的结果很可能让原始的意图面目全非。
挑战之三: 需求实现所必须的社会化协作导致的需求失真、或被“污染”。
需求的交付是一个社会化协作的过程，所有参与其中的人背景、知识、能力、出发点、利益不同，在理解、表达、传递、接收、消化、再传播需求时，都会“解释过滤“一遍，这样的协作过程的产物极有可能让需求意图失真、或被“污染”成另外的样子。
挑战之四：需求的时效性。
在验证假设的过程中，外部市场时刻发生着变化。可能就要上线验证了，市场上突然来了一个其他的产品横空出世，消费者行为因此而改变，“原有的可选项不再是可选项”。
如果我们认识到，需求只是一组假设，那么我们就会：
转变思维——我们的所有工作过程，不再是一个对确定问题求解的线性过程，而是一个构建（Build）- 度量（Measure）- 学习（Learn）的螺旋前进过程，我们会认为“不确定”是常态，积极主动地调整计划以适应变化；
步子迈得更小一点——每次定的“需求目标和范围”会更小一点，这样尽可能让错误的弯路更短一些，验证的成本也更低一些；
尽量缩减验证、反馈周期——因为这样试错成本更低，所以我们就要拼命靠近客户和用户，与他们对话，花精力研究他们、了解他们；
迫切想知道验证结果——所以在在产生需求想法时，就确定好度量指标和验证方法；
为了一开始找到更接近的假设，我们需要对用户、领域问题、行业生态有更为深刻的洞察；
如果我们认识到，需求层层分解会导致需求变形，那么我们就会：
需求目标定小一点，尽量避免不必要的分解；
简化组织结构，层级少一点，减少层层分解；
建立跨职能部门，减少分解；
如果我们认识到，需求的社会化协作（沟通、传递、协调）会导致需求变形，那么我们就会：
统一需求接口，减少沟通节点；
按照产品职责来设置团队，让市场、技术和消费者直接沟通，减少中间环节；
建立跨职能团队，避免部门政治给需求带来的污染；
采用更直接、更简洁、更高效的方式去沟通，减少信息失真；
如果我们认识到，需求是具有时效性的，那么我们就会：
需求目标定得尽可能小，因为目标越大、验证学习周期就会越长，失效的可能性更大；
时刻关注市场变化，随时做好调整转向准备；
所以，需求挑战的应对，不单单是IT团队负责需求的个人和团队的事，更是思维和文化、组织结构、管理流程、领域洞见、沟通和协作能力等各个维度在各个层面的事。
当前，在诸多开始尝试或已经实施敏捷转型的企业里，应用最普遍的还是团队级的“敏捷开发方法“，有关需求的方法和实践，如果浓缩下来，大概像这张图：
回头检视，我们会发现通过图上这些方法、实践和工具，主要是改善了IT交付团队内部的“需求沟通和传递”，通过“小步发布“少量地改善了“时效性”的问题，而针对其他问题似乎没怎么改变。
因此，也出现了类似这样的疑问：“实施敏捷需求分析的效果，也就是团队内合作和沟通更流畅了，对业务也没什么影响啊？”
如果想要全面应对这些需求挑战，则需要应用“精益企业”的指导方法——把敏捷、精益的理念思维应用在与需求有关的组织结构、管理流程、领域洞见、沟通和协作能力等各个维度、各个层面。
另外，“传统上，大多数企业秉承以范围、成本和进度为中心进行交付管理，这使得所有人都迷失了，似乎项目交付就是目的，而忽视了投资本身的初衷所要达到的用户和业务目标，更谈不上持续创新。现代科技企业所面对的竞争环境越加激烈，用户和市场的变化迅速，要能够快速适应变化，真正创造用户喜爱的，有竞争力的产品，并持续创新，需要告别以往多年以项目为中心的管理，建立一种以产品为中心的软件交付模式。
要根据面向业务的能力来建立产品团队，在看待需求时从产品的全生命周期——产品的机会发现、定义、启动上线、成长、成熟以及演化去看待和管理需求。如果尝试给“精益产品需求”下个定义，就是以“精益企业”为指导，以产品为中心，把敏捷、精益的理念应用在产品全生命周期相关的组织结构、管理流程、需求沟通和协作中的方法和实践。
结合第2部分的常见需求挑战，无非就是在组织层面应用精益的思想和原则：
精益产品需求的目标：
通过在组织、团队、个人层面的精益需求发现、管理、沟通和协作实践，来提升组织的响应力和创新力。
“精益产品需求”的原则：
对业务领域、市场、用户需要有洞见，来主动驱动业务变化，而不是仅仅理解跟随业务变化；
真正以客户/用户为中心，像客户/用户一样思考，由客户/用户价值来驱动决策，而不是利用组织政治来决策；
共同一致的需求愿景和目标，高度透明、可视化、协同地、高质量地需求沟通，而不是不写文档、频繁但低效地沟通；
去中心化的产品体系架构和产品团队，负责产品的整个生命周期，而不是项目团队，只注重交付的速率不注重交付的价值；
以业务成效来度量和验证价值，形成价值闭环，而不是单单衡量IT团队的交付效率和产能；
产品的需求，少就是多(Less is More)，做减法；
图6 精益产品需求的价值闭环
“精益产品需求”方法：
产品化方法，区分探索期和拓展期的工作方法
不同产品生命周期的关键方法：
图7 产品的生命周期及关键方法
“精益产品需求”实践和工具：
我们在跟一家国外大型金融企业合作的过程中，他们实施了“以客户为中心”的组织架构重组，他们已实施敏捷转型5年，想借用此次架构重组来做到“精益产品化治理”，并解决“业务需求响应力慢”的问题。 他们面临的具体挑战是：
经过了几十年的运营，IT系统非常复杂，仅客户平台这块新老系统超过200个，相互紧耦合。
以项目团队进行工作，项目之间相互依赖，经常出现因为等待依赖而浪费大量的时间；
项目启动基本上是瀑布方式，概念阶段和启动阶段长达数月；
开发和运维分开，负责维护的团队觉得不被重视，长期士气低落；
他们的改进路线和应用实践如下：
应用实践：
“以面向业务的能力来构建产品团队”，每个产品团队自己规划自己的项目，以持续交付、持续验证的方式来演进自己的“能力”（如发展新产品，退役旧产品）；
每个产品团队设立Product Owner和Product Architect，按照“业务能力职责”，共同规划自己产品体系的发展蓝图及运维支持；
持续的产品需求技能提升训练和实践社区；
产品团队建立后，运维放到产品团队做了之后，发现总体人员规模可以减少1/5 - 目前这1/5的人用来识别创新机会，在团队内开展创新项目。
建立了创新期和拓展期的流程，尝试并逐渐成熟的需求实践包括：MVP，验证板，产品团队（包括Product Owner），可视化运营，用户研究和用户测试，故事墙，看板墙，用户故事，敏捷快速启动，协作式需求工作坊，低保真原型，实例化需求，价值点分析，优先级契约，团队协作契约。
很多企业当面临图4中列出的需求问题时，第一时间想到的就是组织需求分析人员的技能培训，给他们制定一个工作流程，发给他们一个有着“先进实践”的Handbook，然后就期望这些需求问题都能迎刃而解。
但这样过了一年，发现好像没什么变化，那些存在的问题还依然存在。希望通过本文，大家能认识到：在新的数字经济时代下，需求不确定性更强，挑战来自于市场外部、组织内部的结构和管理、能力等多个方面。在实施转型或改进时，企业应该能以一个更系统的视角来看待，真正实现“精益的产品化治理”。
另一方面，从个人和团队来说，图5所展示的“敏捷需求分析”方法和实践依然适用，但应该有两个关键的转变：
一是“产品思维”，“人人都是产品经理”，认识并把控产品的生命期，根据不同的生命期取舍不同的需求实践，全面掌握不同生命期的实践方法；
二是“精益思维”，以业务成效来度量，对需求要有效做减法。
参考资料：
[^1]：Michael Porter, http://www.faz-forum.com/scp/150121SCPPorterHarvardHeppelmann_PTC.pdf.
[^2]：“敏捷方法簇”，指代Scrum、XP等为代表的轻量迭代开发方法。
- 小编推荐 -
总额20W软妹币，全城通缉极客颠覆汽车行业！HOT!!!
回复201501-201606，获取当月精彩洞见合辑
如：想看6月精彩洞见合辑，请回复 201606
若你想去 TW洞见网站阅读所有洞见文章，复制网址在浏览器打开：insights.thoughtworkers.org
阅读全文内容请点击【阅读原文】