文章作者/配图来自ThoughtWorks:亢江妹。
本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。
我们这里说的“需求”,是沿循计算机技术诞生而来的“软件需求”,所以可以先稍稍回溯一下历史。下图是Michael Porter的“IT的三次变革”[^1]。
作者的本意在于看待技术在时代变迁中扮演的角色和地位,我们这里则去看看商业市场需求的变化特点。
图1 Michael Porter IT发展的三个阶段
我想大家看到了这个突出的变化,那就是:普遍来讲,市场需求不确定性越来越高,竞争越来越激烈。
与此同时,如果对比软件开发方法的发展,好像也有对应的三个时代:
图2 软件开发方法的沿革
因此上,在当前高度不确定性的市场环境下,有必要重新定义下“需求”:
需求是“建立在商业、技术和人之间的一组动态的、待验证的假设”;挖掘和定义需求的过程,是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。
下面是我们在提供咨询时收集到的一些常见的需求问题。看起来是不是很眼熟?
图3 组织中常见的需求问题
如果仔细去分析这些问题,本质上会归结为下面的挑战:
图4 需求的多重挑战
挑战之一: 需求产生时的“不确定性”。
产品需求的本质都变成了“有价值的假说”,而不是传统意义上是确定的、一开始就能准确定义出来的。“市场用户需要一匹更快、永不疲倦的马”,是一个“有价值的假说”;“用户需要汽车”则是不断转向、学习的结果。人们善于解决确定性的问题,在面对不确定性的时候,往往束手无策。产品创新连接商业、技术和人,但方向有那么多,该从哪个点开始?如何在首次提出产品想法时,就能(比竞争对手)找出“更靠谱的假设”?这是前所有未有的挑战。
挑战之二: 需求经过层层分解可能完全失去原有意图。
即使在最开始,我们独具慧眼,已经识别出更接近“正确结果”的假设,但在落地实现时,因为组织分工、政治、计划等约束,不可避免地会被拆解成零部件,然后再一一实现,组装完了再去验证。在这个过程中,拆解、组装之后的结果很可能让原始的意图面目全非。
挑战之三: 需求实现所必须的社会化协作导致的需求失真、或被“污染”。
需求的交付是一个社会化协作的过程,所有参与其中的人背景、知识、能力、出发点、利益不同,在理解、表达、传递、接收、消化、再传播需求时,都会“解释过滤“一遍,这样的协作过程的产物极有可能让需求意图失真、或被“污染”成另外的样子。
挑战之四:需求的时效性。
在验证假设的过程中,外部市场时刻发生着变化。可能就要上线验证了,市场上突然来了一个其他的产品横空出世,消费者行为因此而改变,“原有的可选项不再是可选项”。
如果我们认识到,需求只是一组假设,那么我们就会:
如果我们认识到,需求层层分解会导致需求变形,那么我们就会:
如果我们认识到,需求的社会化协作(沟通、传递、协调)会导致需求变形,那么我们就会:
如果我们认识到,需求是具有时效性的,那么我们就会:
所以,需求挑战的应对,不单单是IT团队负责需求的个人和团队的事,更是思维和文化、组织结构、管理流程、领域洞见、沟通和协作能力等各个维度在各个层面的事。
当前,在诸多开始尝试或已经实施敏捷转型的企业里,应用最普遍的还是团队级的“敏捷开发方法“,有关需求的方法和实践,如果浓缩下来,大概像这张图:
图5 当前常用的“敏捷需求分析“
回头检视,我们会发现通过图上这些方法、实践和工具,主要是改善了IT交付团队内部的“需求沟通和传递”,通过“小步发布“少量地改善了“时效性”的问题,而针对其他问题似乎没怎么改变。
因此,也出现了类似这样的疑问:“实施敏捷需求分析的效果,也就是团队内合作和沟通更流畅了,对业务也没什么影响啊?”
如果想要全面应对这些需求挑战,则需要应用“精益企业”的指导方法——把敏捷、精益的理念思维应用在与需求有关的组织结构、管理流程、领域洞见、沟通和协作能力等各个维度、各个层面。
另外,“传统上,大多数企业秉承以范围、成本和进度为中心进行交付管理,这使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷所要达到的用户和业务目标,更谈不上持续创新。现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年以项目为中心的管理,建立一种以产品为中心的软件交付模式。
要根据面向业务的能力来建立产品团队,在看待需求时从产品的全生命周期——产品的机会发现、定义、启动上线、成长、成熟以及演化去看待和管理需求。如果尝试给“精益产品需求”下个定义,就是以“精益企业”为指导,以产品为中心,把敏捷、精益的理念应用在产品全生命周期相关的组织结构、管理流程、需求沟通和协作中的方法和实践。
结合第2部分的常见需求挑战,无非就是在组织层面应用精益的思想和原则:
精益产品需求的目标:
通过在组织、团队、个人层面的精益需求发现、管理、沟通和协作实践,来提升组织的响应力和创新力。
“精益产品需求”的原则:
图6 精益产品需求的价值闭环
“精益产品需求”方法:
图7 产品的生命周期及关键方法
“精益产品需求”实践和工具:
图8 精益产品需求的实践和工具举例
我们在跟一家国外大型金融企业合作的过程中,他们实施了“以客户为中心”的组织架构重组,他们已实施敏捷转型5年,想借用此次架构重组来做到“精益产品化治理”,并解决“业务需求响应力慢”的问题。 他们面临的具体挑战是:
他们的改进路线和应用实践如下:
图9 XX金融企业的需求改进路线
应用实践:
很多企业当面临图4中列出的需求问题时,第一时间想到的就是组织需求分析人员的技能培训,给他们制定一个工作流程,发给他们一个有着“先进实践”的Handbook,然后就期望这些需求问题都能迎刃而解。
但这样过了一年,发现好像没什么变化,那些存在的问题还依然存在。希望通过本文,大家能认识到:在新的数字经济时代下,需求不确定性更强,挑战来自于市场外部、组织内部的结构和管理、能力等多个方面。在实施转型或改进时,企业应该能以一个更系统的视角来看待,真正实现“精益的产品化治理”。
另一方面,从个人和团队来说,图5所展示的“敏捷需求分析”方法和实践依然适用,但应该有两个关键的转变:
参考资料:
[^1]:Michael Porter, http://www.faz-forum.com/scp/150121SCPPorterHarvardHeppelmann_PTC.pdf.
[^2]:“敏捷方法簇”,指代Scrum、XP等为代表的轻量迭代开发方法。