精益产品需求的要义

2 评论 9310 浏览 83 收藏 21 分钟

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

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

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

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

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

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

如果我们认识到,需求是具有时效性的,那么我们就会:

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

所以,需求挑战的应对,不单单是IT团队负责需求的个人和团队的事,更是思维和文化、组织结构、管理流程、领域洞见、沟通和协作能力等各个维度在各个层面的事。

4. 精益产品需求是什么

当前,在诸多开始尝试或已经实施敏捷转型的企业里,应用最普遍的还是团队级的“敏捷开发方法“,有关需求的方法和实践,如果浓缩下来,大概像这张图:

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

回头检视,我们会发现通过图上这些方法、实践和工具,主要是改善了IT交付团队内部的“需求沟通和传递”,通过“小步发布“少量地改善了“时效性”的问题,而针对其他问题似乎没怎么改变。因此,也出现了类似这样的疑问:“实施敏捷需求分析的效果,也就是团队内合作和沟通更流畅了,对业务也没什么影响啊?”

如果想要全面应对这些需求挑战,则需要应用“精益企业”[4]的指导方法——把敏捷、精益的理念思维应用在与需求有关的组织结构、管理流程、领域洞见、沟通和协作能力等各个维度、各个层面。

另外,“传统上,大多数企业秉承以范围、成本和进度为中心进行交付管理,这使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷所要达到的用户和业务目标,更谈不上持续创新。现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年“以项目为中心”的管理,建立一种以产品为中心的软件交付模式”[5]。要根据面向业务的能力来建立产品团队,在看待需求时从产品的全生命周期——产品的机会发现、定义、启动上线、成长、成熟以及演化去看待和管理需求。

如果尝试给“精益产品需求”下个定义,就是以“精益企业”为指导,以产品为中心,把敏捷、精益的理念应用在产品全生命周期相关的组织结构、管理流程、需求沟通和协作中的方法和实践

结合第2部分的常见需求挑战,无非就是在组织层面应用精益的思想和原则:

精益产品需求的目标:

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

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

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

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

“精益产品需求”方法:

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

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

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

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

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

以一家国外大型金融企业为例,他们实施了“以客户为中心”的组织架构重组,已实施敏捷转型5年,想借用此次架构重组来做到“精益产品化治理”,并解决“业务需求响应力慢”的问题。 他们面临的具体挑战是:

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

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

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

应用实践

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

5. 写在最后

很多企业当面临图4中列出的需求问题时,第一时间想到的就是组织需求分析人员的技能培训,给他们制定一个工作流程,发给他们一个有着“先进实践”的Handbook,然后就期望这些需求问题都能迎刃而解。但这样过了一年,发现好像没什么变化,那些存在的问题还依然存在。

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

另一方面,从个人和团队来说,图5所展示的“敏捷需求分析”方法和实践依然适用,但应该有两个关键的转变:

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

参考资料:

[1]:Michael Porter, 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-product-centric.

 

作者:亢江妹,ThoughtWorks的首席商业分析师、咨询师,中国区行业研究团队的负责人,负责金融(银行和保险)企业数字化转型的研究,以及精益产品创新方法的咨询。

本文由 @亢江妹 原创发布于人人都是产品经理。未经许可,禁止转载。 亢江妹

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 深刻专业!资料可分享?

    回复
    1. 可以分享哇,附上文末作者信息就好 。

      来自北京 回复