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


    一、客户需求分析

    需求的三个层次: 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)

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

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

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

    举一个例子。一家包装供应商的客户是跨境电商,供应的产品是大型家具的包装。这是非常典型的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做好需求与进度的管理

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

    三、用好WBS,「目标感+分解能力」

    “会工作的人,就是在他的脑子里,能画出那个终极的图。” 这个终极的图,就是WBS,以终为始,往下细化成可执行的具体步骤。从这句话里面,有两个关键词:“终极”+“画出”。一个是结果,一个是过程。总结来说就是你的「目标感+分解能力」。能从结果出发,一步一步拆解出具体的步骤并执行好它,达到预定的目标,这样的人,才算是一个“会工作“的人。

    WBS就是一个可以帮你理清头绪,根据目标做好计划的工具。WBS最大的用处就是帮你拆解任务,使其变得可实操。

    完成一个大目标,就如同吃掉一头大象,需要一层一层、一级一级的逐步分解细化为一个个小的任务单元,从而把每一个小的任务单元完美的完成,大目标,自然也就完美地完成了。

    怎么搞定一个拿得出手的WBS, 第一步就是了解规则,在规则清楚的前提下,如果你能“玩“好规则,加上技术辅助等等,你一定是个高手。

    01 “守规矩”——WBS的分解原则

    WBS看起来只是一张图,但也有它的「游戏规则」:

    1、100%原则

    拆分的任务要100%包含所有交付物,每一层分解的子任务也要100%覆盖它的父级任务范畴。

    2、要有合理的工作包大小.80小时原则

    工作包不是越细越好,而是可交付、可分配、责任到人。分解的最小工作包要保证一个人能在80小时内完成的范围,如果大于和这个范围,就需要继续分解,因为大的工作包会有暗藏风险。

    3、元素互斥,互斥就是相互独立且完全穷尽。

    「相互独立」就是不重复造轮子;「完全穷尽」才能做到无遗漏不误事。

    比如你把采购水果和采购栗子并存,就是不合理的拆分。

    4、围绕产出/面向交付成果,以终为始,盯着目标做事-----------------不要按过程分解

    在列举WBS工作包时,要按照期望的产出物计划,而不能只是规划行动事件。说人话就是盯着目标做事。作为项目负责人,要避免这样的情况发生,必须从你要的产出结果出发去做计划,而不是仅仅规划了行动事件。

    02 “上辅助”,要无重复,相互独立,不相互包含,完全穷尽,无遗漏;滚动式规划,渐进明细;

    1-MECE原则 相互独立 完全穷尽

    听上去很复杂的样子,其实很简单,MECE法则就像是拼图游戏,把所有的拼图碎片拼出一个完整的图片,如果拼的正确,最后一定是一块不多,一块不少,刚刚好构成完整的图片。

    MECE用在项目WBS分解中,就是要做到不重叠,不遗漏——重叠了成本增加,遗漏了,风险巨大。

    2-滚动式规划原则 颗粒度近细远粗

    项目初期,很多信息都是需要随着时间的推移进行逐步确认,如果有些信息不明确的情况下,做出详细的分解就会造成管理时间的无效浪费,毫无意义。

    03 WBS的分解方式

    WBS常见的分解方式总共有7种:

    ① 按产品的物理结构分解

    ② 按产品或项目的功能分解

    ③ 按实施过程分解

    ④ 按项目的地域分布分解

    ⑤ 按项目的各个目标分解

    ⑥ 按部门分解

    ⑦ 按职能分解

    04 WBS的编制步骤

    05 WBS的检验标准

    一个人的核心竞争力取决于他的底层框架和可迁移能力。

    学会一个工具或者方法,接触的多了,你会发现我们其实掌握的是底层逻辑,从一个点可以链接更多的领域和行业。熟悉我的朋友应该知道,我经常强调一句话「万物皆可项目」,项目化思维可以用来解决任何事情。

  • 相关阅读:
    14条最佳JavaScript代码编写技巧
    记一次SQL优化
    C语言牛客网(NowCoder)刷题篇
    Windows上安装pyenv,以及pyenv切换环境不生效的问题
    Python中import的as语法
    什么是DNS缓存?DNS缓存有哪些作用?
    产品团队的需求验证和确认
    不止于观测|阿里云可观测套件正式发布
    设计模式-装饰者模式
    (附源码)springboot大学体育赛事管理系统 毕业设计 180923
  • 原文地址:https://blog.csdn.net/u010025781/article/details/133781175