PBA.客户需求分析 & 需求管理

一、客户需求分析

1 需求的三个层次: Requirement/Wants/Pains

大部分人认为,产品满足不了客户需要,是因为客户告知的需求是错误的,这听起来有一些道理,却没有任何意义。不同角色对于需求的理解是不一样的。在客户的需求和厂家的需求之间必然有一定差距,甚至可以说是鸿沟。如果客户提的需求非常专业,反而是一件比较糟糕的事情。比如,华为提的需求非常专业,那么你在需求理解上就赚不到它的钱,只能辛辛苦苦挣点加工费。

通常,我们可以把需求可以分为三个层次:

  • Requirements:明确的功能、性能要求,客户已经告诉你这个事情如何实现,确定要的一个东西;
  • Wants:客户确定想要一个东西,但是不确定如何实现,这是一种主动需求;
  • Pains:客户不想要,又不得不解决的东西,也叫痛点,这就是一种被动需求。

很多时候,客户告知的可能是要求(requirement)。它可能是一种产品需求,也可能是一种规格(specification),清晰告知你产品的功能、性能、尺寸等。但有的时候,客户告知的并不是一个requirement需求,而是一个潜在需求(want)。比如,苹果需要一个行业最先进的电感,但先进到什么程度,它自己也不知道,只知道要比原来更好,是别人做不到的。

还有痛点需求(pain)。客户不想要,也不主动追求,但不得不解决这个问题。比如,政府的环保要求,对于制药厂来说,它可能并不想解决这个问题,甚至想把污水直接排放,因为这样成本最低。但现在医药公司都实行牌照制了,而要申请到牌照,就必须通过安全环境评审,这就是痛点。

**我们从一个故事来看want与requirement需求的区别。**有一次,我带爸妈去吃日本料理,这家店是我经常去吃的,我觉得海胆特别好吃,于是就想让老爸尝尝。然而,老板了解到我爸肠胃不是很好之后,就给我推荐了银鳕鱼,因为海胆非常伤胃,而银鳕鱼对胃更好一些,而且煎的银鳕鱼也很美味。让老爸吃得健康开心,是我真正的(want)需求。老板基于我的requirement(海胆)之后去确认我的want(健康好吃),又提供了一个更好的替代requirement(银鳕鱼)。

所以,客户告诉我们的需求不正确,不准确、不完整,都是很合理的。这个时候,我们需要做的事情就是把requirement跟want去做一一对应,要拨开迷雾、去伪成真、去粗取精,这才是我们的价值所在。

我最近在服务一个餐饮的客户,他们用了这个方法就能把需求做得更准确,觉得非常有价值。餐饮的难点是可复制性,关键的解决方案是各个环节的标准化。比如服务态度,是典型的want需求,如果转换成上菜周期,环境的清洁程度等requirements 需求,更容易标准化。比如,好吃也是want需求,翻译成requirement需求是菜的烹饪标准:使用的是高温油还是低温油?是菜籽油还是花生油?原材料是否地道?食材是否新鲜?什么时间内食用口感更佳?这就是具体的requirements需求。

2. 企业需求和个人(岗位)需求

在ToB业务中,客户需求又分成两个维度,一是企业需求,一是岗位(个人)需求。

**但在企业里,真正做决策的岗位的需求才是真正的需求。**所以,有时候企业需求是很虚的,甚至是假的,意义不大。在市场交易地图中有决策链,其中有做最终决策的决策者,也有不能做决策但可提出否定意见的岗位(如品质主管),他们的需求才是真正的需求。

案例:华为To B业务决策中的个人需求

2009年,华为的英国客户电信运营商出现一个痛点,因为3G和2G的业务流量超过了网络的容量,导致电话经常打不通或者3G网络断网,客户投诉很多。基于这样的背景产生了需求。但如果仅仅这样理解需求,华为提供相应的2G/3G解决方案,是远远不够的。

在这项业务中,有三个核心的决策者。

  • **第一个角色是CFO。**在2008年之前,CFO在决策链中几乎没有话语权。但2008年发生了比较严重的经济危机,没有足够的财政支持运营商网络的扩展,所以CFO变成了一个拥有一票否决权的决策者。CFO的核心需求是扩容和新建站点的单位成本必须大幅下降,所以倾向于引进华为。
  • **第二个角色是CTO。**在2008年之前,CEO在整个决策链里面几乎占了80%的决策力。但是因为网络设备很赚钱但又很复杂,所以CTO也有了一部分话语权。CTO注重网络的稳定性,希望有高质量的网络。当时爱立信的网络设备最稳定,质量最高,能减少客户的投诉,所以,CTO倾向于选择爱立信。
  • **第三个角色是运营总监。**因为2G网络和3G网络混合在一起很复杂,所以他期望降低运维的难度。他也希望供应商能提供7*24小时服务,他倾向于选择原有的供应商诺基亚。

所以,这三个角色的需求是矛盾的。 至少CTO跟CFO的需求很矛盾,CTO希望用最好的,但价格更贵;CFO要大幅降低成本,坚定地认为应该引进华为。企业需求一定是企业中关键角色的个人需求,而这些个人角色之间的需求往往是矛盾的。**在其中,我们应当遵循权力更大的原则。**比如,在这个案例中,CFO的权力是最大的,拥有一票否决权,因为这个客户企业面临着很大的经济危机。

在一个项目中,可能90%的需求都没有价值,但是你需要把剩下的10%找出来,而那10%中你要找到目标客户关键岗位的需求,这是客户需求分析的原则。

在ToC业务中的逻辑可能没有那么明确,但也存在。比如,经销商的需求也很重要,但也在于经销商的关键决策者的个人需求。再如个人消费者的需求也是如此,有大众消费者的需求,也有KOC的需求,往往KOC的需求才更有价值。

3. 产品需求:供应商的视角小于客户视角

对于厂家(供应商)来讲,需求的理解是把客户需求转化成产品需求,这样才能开发出相应产品、解决方案或者服务。

从这个维度看,供应商的视角一定是小于客户视角的。 作为供应商,可能要和其他供应商一起组建一个数字化工厂,而在这个工厂中,你只提供了一种设备,你需要满足在这个场景的需求,而客户要满足这个场景中的所有需求。所以,供应商看到的需求天然小于客户看到的需求。实际上,厂家看市场,应该要扩大到客户的视角,要站在客户的角度去看客户所认为的需求。

提到产品需求,很多人认为是产品的尺寸、功能、性能(功率、Q值、灵敏度)等等。

华为给产品需求做了一项定义:产品需求=客户问题+解决方案==》解决客户问题

比如,一个学校客户给华为提了一个需求:希望在CC08机(一款程控数字交换机)实现晚上12点到早上8点切断电话。但依据法律要求,电话机应该随时都能拨通110和119,所以切断电话是不合适的。客户真正的需求是因为有人在那个时间段打电话,影响了他人的休息。应该通过行政纪律来解决这个问题,谁打电话就进行处罚,这才是真正的产品需求。

所以,提到产品需求,不能只想着产品,而是要解决客户的问题。

比如,一家客户提出了交期从30天缩短了20天的需求。交期从30天缩短到20天,对所有供应商都是非常困难的。客户是电商,它的需求会产生爆发,爆发之后需要快速地交付给消费者,所以希望让交期缩短。其实客户真正的期望不是要把交期缩短,而是需要做好备货。

但备货对于供应商和客户而言,都有风险,所以把备货的风险分担原则设定清楚才是更好的解决办法。因为将交期缩短对于很多供应商来说,是一个无法解决的问题。但解决掉备货的风险分担问题,就可能让交期变得更短。所以,基于客户问题,解决客户问题的方案,才是真正的产品需求或者供应商需求。

从客户的需求转化成产品需求是一件非常重要的事情。这是供应商的职责所在,不是客户的职责所在。同时,这也是供应商价值的体现(赚钱的点)。

4。 客户需求的参考模型:$APPEALS

IBM的需求分析工具$APPEALS(产品差异化模型),**可以说是需求分析的最好用的一个工具,**华为在引入IPD时也用了这个工具。

$APPEALS需求分析型模型可以用来理解客户需求,同时也可以进行竞争分析。通过该模型,可以分析出在哪些维度上我们比竞争对手更占优势,做到知己知彼。

$APPEALS(产品差异化模型)把需求分成八个维度:

1)需求一:$(价值或代价) 客户希望为其寻找的价值付出的代价。其中,价格是核心的一部分,但不是唯一。

比如,客户希望供应商帮助提高产品的外在品质感,这样营销的效率会更高。本质上看,客户并不是让产品的成本更低,而是希望设计方案更有传播性,这样就能提高产品的营销效率。

**2)需求二:可获得性(procurability)这是非常容易被遗忘的需求。**别人知不知道你的存在,就是典型的可获得性。

比如,餐饮品牌,在没有数字化的时代,店铺的位置很重要,它需要很强的曝光量和很大的人流量,这是典型的解决的可获得性的需求。

在ToC产品上,渠道覆盖和品牌广告都变得非常重要,不管是品牌广告还是渠道覆盖,很多时候解决的都是可获得性的需求。

在ToB产品上,可获得性也非常重要。比如,宁德时代要求供应商提供一种粘胶剂,这种粘胶剂要求非常先进,既要解决防火性,也要解决导热性,还要解决连接性。

某材料供应商在过去的五年到十年内,聘请了大量博士在这个领域做了研究,所以最终进入宁德时代的潜在供应商名单。而另外一个供应商没有做过这项研究,就没有入选。在研发类业务中,提前投入就是为了进入供应商名录,如果没有提前投入,客户直接就把你踢出供应商名录了。

**3)需求三:包装(Package)**既包含产的外表包装,也包含软件的可视化的美观感。

**4)需求四:功能性(performance and function)**比如,餐饮的口感、味道,食材的健康程度,包括上菜的速度和服务的温暖性等。

5)需求五:易用性(easy to use)

比如,化妆品要导入到皮肤层中去,需要一个导热的设备来帮助,一套简易的美容设备就可以让化妆品的易用性提高得更多。在ToB业务中也一样。SaaS软件系统易用性非常重要。**易用性不仅有外部的易用性,还有内部的易用性。**比如,内部的生产制造、仓储物流、安装测试等易用性需求。

6)需求六:保证(assurance)

**保证有前保证和后保证。**前保证(insurance)是过去已经保证了安全。比如餐饮,过去没出现过食品安全的事故等。后保证是一旦出现了问题,给予的赔偿。比如,一套网络系统,出现了崩塌,损失将以数以亿计,同时赔偿也会数以亿计。

**7)需求七:生命周期成本(life cycle cost)**一个产品的生命周期越长,成本就越低。当然,生命周期成本不仅包括可以使用的时间成本,也还包括使用的能源消耗和维护成本。

8)需求八:社会接受程度(Social acceptance)

什么"形象"可以促进客户购买我们的产品?客户如何获得这些信息?包括品牌、口碑、法律关系、社会责任、环保安全等等。

基于这个工具,我们可以对产品以及市场上的竞品进行评估,分析优势和劣势(根据权重所占比例的优先顺序发现差距和优劣势),确定策略,最终完成满足客户需求的交付,甚至超出客户的预期。

5 客户需求与产品需求的转化

举一个例子。一家包装供应商的客户是跨境电商,供应的产品是大型家具的包装。这是非常典型的To B业务。

客户有很多核心岗位,有美国终端开发采购经理;客户包装设计团队;代工厂采购经理;代工厂生产经理;客户包装项目经理;客户品质经理;客户工厂经理等。

这些角色都会基于自己的岗位提出各种需求,有的是requirement需求,有的则是want需求。这时需要一一对应将客户的want需求翻译成requirement需求。

比如,在保证需求上,客户品质经理要求产险退次小于800DPPM,产品良率大于99%,这是典型的requirement需求。他真正的want需求是产品品质保障和准时交付的保障。

比如,在可获得性需求上,客户包装设计团队要求碳排放要符合美国的法规标准(LCA),这是客户提的requirement需求。满足美国碳排放的法律法规要求是一个很高级的需求,所以在方案设计中,去塑化变成了一个核心的需求。

但是,它背后的want需求是在满足美国法律法规的情况下,还要满足时效性。

为什么这么说呢,因为在大型家具业务中,时效性很重要。新家具要快速推向市场,尽快交付给客户,一旦错过时间周期,产品将会很难销售。所以,一定要在更短的时间内提供一个去塑化的新型材料的解决方案。

无论客户告诉你的是requirement需求还是want需求,都要做一定的翻译,把requirement跟want一一对应,这样就能大幅提升需求的完整性和准确性。

完整性基于角色的完整,角色的完整带来需求的完整;如果把want与pain需求同requirement需求做一一对应,需求就会变得更准确。

当我们把需求梳理出来,要把requirement跟want进行一一对应,然后再进行分类。

怎么分类呢?

一个日本经济学家将需求分成了三类:基本需求(basic);满意需求或期望需求(satisfied);兴奋需求或特好需求(attractive)。

基本需求是必须满足的,否则客户就直接把我淘汰掉了,但不会带来太大的竞争力。

期望需求是满足客户需求程度越高,客户越开心;相反,满足程度越低,客户就越不开心。期望需求满足得越多,竞争力也就越强。

兴奋需求,如果没被满足,客户是可以接受的,如果你满足了,客户觉得非常开心,这也是典型的差异化需求。

最终,我们把它绘制成一个图标(如下),所有的分析就一目了然了。

很多时候,我们没有兴奋需求,怎么办?

这需要你把某些期望需求转换成兴奋需求。比如服务,服务的有效性、服务的温度只算是期望需求,但一定时期内,海底捞把服务做成了兴奋需求。再如价格,通常是期望需求,但小米最先把收集做到1000元以内,这就成了兴奋需求。

当然,对于很多做新业务的来说,你可能找出十几个兴奋需求,但是有可能大部分都很难解决。当然,你不用解决所有的问题,这个其实要看你的竞争环境。如果你能做到而别人做不到,就能构建你的核心竞争力,更早做到可能很重要。所以,华为会投大量的研发去解决客户的兴奋需求。

*****6.***需求评价标准,**在所有的需求做完之后,还要保证需求的完整性和需求的准确性,这需要有明确的需求质量评价标准。

1)体现产品包的定位

产品包的定位体现了产品或者解决方案的定位。

**首先,匹配目标细分市场。**市场通常是分散的,产品不可能满足所用用户的需要。所以先要匹配天使客户和战略客户的需求,如果是To B产品,则要满足典型企业客户中核心岗位角色的需求。

**其次,要满足未来上市后的需求。**比如,产品开发周期是六个月,产品必须满足六个月后的需求,如果仅满足当下,六个月后产品就没有竞争力了。

**最后,体现差异化定位。**最好有兴奋需求,如果没有兴奋需求,就要利用需求分析工具保证需求是高质量的。

2)需求来源全面

在确定了需求的目标客户以及需求产品的定位之后,要保证需求来源是全面的。

需求来源通常有四个:

第一,客户需求清单和隐性需求;

第二,通过对标竞争对手,保证需求完整性;

第三,内部的再可制造性,可生产性,可运输性,可测试性等需求;

第四,行业标准及规范。

3)内容的明确性

**第一,详尽描述。**微软、华为的标书中需求描述非常详尽,当然,不同的行业对有不同的要求程度,但都要保证需求是确定的。

**第二,没有歧义。**对需求描述准确,不会产生其他的理解。

第三,明确验收标准。

比如,小天才手表要求包装供应商提供一款升级包装,提出了三个wants需求:其一,看起来的品质高;其二,包装要有设计感;其三,包装要有中国元素。供应商为其设计了关于敦煌文创的高品质包装,设计过程很顺利,客户也确认了样品。

结果批量生产时,发现打开几次后,中间的缝隙达到了0.5毫米,看起来品质感不高。但如果做到0.2毫米,品质感就很高了。

按包装厂的能力,完全可以做到0.2毫米,只不过成本要高5元钱。但这5元钱相对于2500元的手表来说,客户并不会在意。这就是典型的没有明确验收标准。

实际上,0.2毫米就是典型的requirement需求,但供应商并没有同客户去确认这个需求,也就造成了巨大的损失。

经常有人抱怨为什么客户的需求变来变去,其实客户和供应商之间对于需求的理解必然存在差距,但是有了以上的方法论和工具,做出的需求就是比较高质量的了。■

二、需求管理-需求管理的7个关键点

需求管理对于项目经理来说也是一项非常重要的能力,管理需求几乎贯穿了整个项目管理的周期。它不仅能决定产品是否有意义,同时也能决定项目是否可以成功。可以说它在影响相关目成功的因素中占比能达到50%以上。虽然在以往的项目管理实践中,需求管理似乎并没有收到很多PM太多的关注。但随着时代的迭代,项目需求变更的频率也在逐渐变高,它的重要性就慢慢凸显了出来。有系统学习过PMP的老友都知道,其实需求管理一直是项目管理的重点,PMP也提供了很多系统的思维方法来提供解决方案。

要做好需求管理,第一步就是整理需求并进行分类,其次对项目需求优先级进行分析。需求这事由人不由己,项目经理能做的有哪些呢?

01 合理的整体需求变更控制流程

1、提出与接受变更申请

项目干系人都可以提出变更,提出可以由不同的方式,口头、书面均可,但变更应及时以正式方式记录。

2、对变更的初审

这个环节主要是通过对变更申请文档的审核来实现。项目经理、项目关键相关方对变更施加影响,确认变更的必要性,确保变革是有价值的;针对变更记录的格式、完整性做校验,确保变更评估所需的信息是准备充分的;

与干系人一起,就供评估的变更信息达成共识。

02 完善需求管理的定义环节

通常只有一个初步的需求说明,没有定义详细的需求说明。

甚至有一些公司或项目团队不编写需求规格说明书------这不仅不利于需求的管理,更是企业组织资产流失的隐患。需求的定义是在收集了客户的需求后,对需求的进一步确认。因为客户往往是根据某一方面的需求提出意见的,至于整个软件系统,不存在与其他需求的关联、影响、冲突、限制,也没有明确的具体度量标准和验收标准等等。

这些需要结合需求完整性进一步定义。我的建议是,明确界定需求分析的输出标准,规范需求规范和需求规范模板,并根据需求来严格执行。

04 完善需求确认验证环节--完成定义

当"完成"需求收集时,很多人认为下一步就是立即进行需求分析、产品设计,而忽略了什么叫做"完成"。需求收集时,只能算作自认为的完成,而实际上,并没有得到客户的确认,因为通常情况下,需求的收集是来自多个客户和多个相关方的。

对于每个客户来说,他们不一定知道什么是"完整"的需求集合。

客户A收集到的需求是否与客户B的需求相冲突,是否认为有调整和补充的必要,都是悬而未决的问题。因此,要求客户代表一起进行需求评审,得到相关方对需求的一致理解,并获得利益相关人对要求的承诺,是非常重要的。

这一步是需求验证的关键,是减少后续需求变更的重要保障。

05 控制管理需求变更

关于需求变更的常见错误是,需求变更不大,直接做就可以了,而当一个小小的变更不断累积,导致最后无法按时、按计划实现,就已经来不及了。

关键的问题是:变化没有被记录下来,靠感觉管理。正式的变更记录是基础,然后是变更控制,没有一个变更控制标准。

**需要提前达成共识,确定何时可以由项目经理直接决定,何时必须由变更控制委员会批准。**这里需要注意的一点是,当变更提交到变更委员会审批时,其目的并不是盲目地拒绝变更、减少变更,而是更充分地评估变更所带来的影响,从而确保在合理的时间、资源、成本下,能够实现必要的变更。

06 需求范围的确定、核实与控制

在需求管理上要注意的是,整合时间、资源、成本等因素,进一步对范围进行确认、查核与管制。

需要注意的是,这项工作并不只是在需求完成后才进行,而是需要在整个项目过程中不断地关注。这一步往往没做好也是可能由于多方面因素造成的,但主要原因在于:

• 没有流程规范,工作环节遗漏,比如没有按照收集需求、范围定义、创建WBS、范围核实、范围控制的流程步骤开展工作

• 有流程规范,但往往造成不容易控制的关键在于前一步WBS工作不到位,导致评估出现偏差,不能够有效支撑范围的核实与确认8做好需求与进度的管理。

7做好需求与进度的管理

当需求范围变更时,没有充分评估对进度等其他方面的影响,导致进度延误。尤其是当需求和进度被分配给项目组中分别负责项目的两个人,不能有效协调时,更容易被忽视。

相关推荐
北京云巴巴信息技术有限公司2 天前
TAPD卓越版的全面评测:超强的功能与用户体验优势
产品经理·需求分析
AmHardy3 天前
系统架构设计师 需求分析篇二
系统架构·需求分析·面向对象分析·分析模型·uml和sysml
黄焖鸡能干四碗4 天前
【大数据方案】智慧大数据平台总体建设方案书(word原件)
大数据·运维·系统安全·需求分析·规格说明书
AmHardy4 天前
系统架构设计师 需求分析篇一
架构·系统架构·需求分析·结构化分析·核心模型
懒人w8 天前
案例题——需求分析
需求分析
冰暮流星8 天前
需求分析例题
需求分析
吕永强9 天前
面向对象需求分析
需求分析·uml·类图·用例图·顺序图·状态图·活动图
吕永强9 天前
需求分析概述
需求分析
cong*9 天前
数据库设计中的需求分析
数据库·需求分析
茜茜西西CeCe15 天前
软件工程知识点总结(2):需求分析(一)——用例建模
软件工程·需求分析·uml·用例图·活动图·用例建模·ooa