价值需求分析

价值需求是组织应用类软件系统需求的灵魂和方向。如果这部分相对薄弱，就会使项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。

绝大多数情况下，用户提出的需求都附带自以为正确的解决方案。

黄金思维圈理论将思维模式分为三层，即 Why、How、What。多数人在思考问题时，往往喜欢从外层开始，在表层探索，却很少深入到核心的内层。如果思考时能够从最里面的内层出发，展开到 How，再到 What，就会更容易洞悉问题的本质，并做出正确决策。

在产品设计和需求分析工作中，用户提交的需求往往是在 What 层面思考的。产品经理应该帮助用户从思考的外层逐步深入到内层，找到核心需求之后，再反向向外延伸，寻找更多解法。

在分析核心诉求之前，产品经理要想清楚：需求本质上是要解决谁的诉求、谁的痛点。这个痛点既可能来自需求提出人，也可能来自功能使用人。

通过对需求不停地问“为什么”，其实可以发现很多问题点和改进机会点。问题挖掘的深度和方向，需要产品经理自己做好把握和判断。

对需求做深层次的洞察，不是没完没了地问“为什么”就足够了。一方面要有灵活的思路和探究到底的决心，另一方面更要有对业务的深刻理解和认识，尤其是后者更为重要。

对于 B 端产品设计来说，如果产品经理对业务理解不够深刻，是很难洞察需求本质的。

需求的强烈程度代表了用户对痛点的忍耐程度。如果需求强烈，说明用户痛点显著，需求真实性高；如果需求不强，说明用户痛点不显著，甚至面对的可能是一个伪需求。

如果需要判断需求的强弱程度，或者判断需求的真实性，可以使用两个方法：

正反两问：产品经理总是习惯询问用户，如果做了某某功能，对方是否喜欢、是否会用。除了正向询问，还应该采用逆向询问：如果不做某某功能，对方的感受是“我很喜欢”“理应如此”“无所谓”“勉强接受”，还是“我很不喜欢”？
询问目前痛点的解决方法：如果用户表示需求很紧急，但是在被问到目前问题是如何解决的时候，又表示目前问题并没有得到解决，那么就一定要注意，这个需求对于用户而言，可能并不像所说的那么紧急。如果真的是很紧急的痛点问题，即便没有人去实现相关功能，用户也一定会自己去想办法解决。

具体而言，价值需求分析分为三大步骤：

目标愿景分析。
干系人识别。
干系人分析。

首先看第一个大步骤，目标愿景分析。

需求、预期、现状这三者的关系是：需求 = 预期 - 现状。

在任何一个时间点上，用户的预期和现状的可能状态只会有三类：

预期高于现状：在这种情况下，用户通常会比较积极地配合需求调研。只要调研方法得当，就能够很好地识别出目标。
预期等于现状：在这种情况下，他们通常会对变化表现得不积极，基本上很难用直接的调研方法来获取需求。
预期低于现状：在这种情况下，用户甚至会抗拒变化，对需求调研表现出消极态度。

所以，如果客户对现状满意，就需要产品经理提出新的预期，让他产生需求。这就是所谓的机会场景，即用户无意识需求。寻找机会场景的关键在于从用户角度思考，而不是从系统中找优点。

如果客户的预期高于现状，那么他就会意识到这种问题，或称为意识得到的需求，通常可以通过访谈获得。但不管是问题场景还是机会场景，目标分析主要针对的是项目发起人、出资人和项目属主。

项目发起人，也就是项目的提出者，通常会对预期与现状有清晰的了解，同时也对问题的解决或机会的创造最为重视。

出资人一般是为项目提供预算的人或部门，他们通常对项目的成本和效益更为关注。当项目发起人不具备预算审批权利时，就会寻找出资人的支持。

项目属主负责推动项目实施。当项目发起人和出资人认为自己直接推动项目会有阻力时，就会寻求一个属主来推动。

目标的描述方式也分为三类：

定向描述、定性描述：也就是从总体属性、趋势、宏观的角度来说，这种方法的描述只是指出一个模糊的方向，无法有效界定系统范围，通常是空洞无物、无法验证的，因此应该避免采用。
定量描述：也就是从微观的角度，使用具体、精确的数据来描述。最典型的就是 SMART 原则：具体的 Specific、可衡量的 Measurable、可实现的 Attainable、有相关性的 Relevant、有实现性的 Time based。这种描述最精确，而且易于验证，所以只要有可能，都应该做到这种程度。但现实是有时会难以达到。
场景化描述：也就是用故事场景来描述用户的期望。这是一种折中方案，真实、易于理解、可以验证，同时感染力强。

当然，在实践中可能会遇到目标十分清晰明确的项目，这时可以考虑跳过目标愿景分析。最典型的场景有三种：

相关法规改变，需要改造系统以适应新法规需求。这时，监管部门、上级部门的验收标准就是目标。
企业因为开拓一项新业务，需要改造系统以便提供支持。这时，新业务上线就是目标。
为业务服务提供一种新的渠道。这种情况也可以弱化目标分析工作。

但因为目标分析是整个需求分析工作的灵魂和方向，所以跳过这个环节时一定要谨慎。

目标分析又可以再细分为多个步骤来进行。

第一个步骤肯定是访谈问题。通过与项目发起人、出资人、项目属主进行访谈，了解他们对项目的预期和现状之间的差距，从而定义出系统要解决的问题。

在这个步骤里会遇到一种情况：有些时候，项目发起人会因为受到外部因素触动而提出一个项目。这个时候通常只有一个宏观方向，但具体要解决的问题不够清晰，从而给目标分析带来困难。

对于这种情况，应该先识别项目的初因，然后根据初因选择相应的对策。最常见的初因有三种：

参观考察：产品经理应该还原用户观察的内容，使问题场景化，以便理解其目标。
竞争对手的动向：这种初因对需求分析人员的技能要求会更高一些，需要从宏观视角进行总结和抽象，才能更好地实施。
热点以及新技术趋势：只有真正了解项目发起人对新技术的看法和理解，才能够揭开后面的真实需求。

当然，还有另外一种情况，就是内部提出的项目。通常已经有了基本思路，发起人已经认识到了预期与现状的差距。针对这种情况，可以通过有效访谈来识别问题场景。要想提高访谈质量、获得有效信息，重点在于提高自身的提问技巧。

这个环节结束，就进入研讨“机会”环节。产品经理可以协同领域专家一起发现当前或潜在的新业务，提出相应的机会场景。新业务带来的机会可以从不同角度发掘。

标杆企业：标杆企业不是提供最多生意、提供最多钱的客户，而是在某个特定领域商业模式领先的企业，是很多成长中企业的未来。从这种差距里，总能够找到新的机会场景。
同行：同行经常是此起彼伏的领跑者。关注跑在前面的同行的所作所为，也可以发现很多有机会的机会场景。
行业融合：行业与行业之间是相互融合的。任何商业在本质上都有很多相似之处，有时候观察其他行业也能够找到机会场景。
新技术：如果从新技术角度去挖掘机会场景，思考要点有两个方面：首先是关注新技术的发展路线、应用趋势，从中收获灵感；其次是关注客户的业务问题、痛点，或者当前系统存在的遗憾与不便。

当然，对于组织应用系统而言，新一代的管理层员工都会因为新的价值观带来新的思路，也就意味着带来新的机会。

经过充分研讨之后，就进入了定义问题或机会的环节。

结合我们前面所说的目标描述方式，在这个环节无法量化的时候，千万不要使用定性描述，可以先讲讲故事。实际上，即使可以量化，也最好先讲故事，再讲数字。

描述问题时，如果收集到多个问题场景或者机会场景，应该逐个进行定义。

想要成功描述一个问题，关键在于把握几个要点：

业务态：因为要讲给客户听，所以一定要从业务角度阐述问题或者机会，而不是从系统角度阐述。很多需求原来都有技术背景，所以经常容易陷入技术实现细节里。产品经理在描述问题时，一定要有意识地提醒自己注意思维角度。
客观性：产品经理在描述问题时，要想确保有说服力，就一定要保持客观性，即不加入主观判断，仅仅真实地还原问题。
匹配性：因为项目的目标和愿景针对的都是高层管理者，所以定义的问题要能够与高层管理者的关注视角相匹配。首先，经营层面的问题通常是高层管理者最关注的；其次，涉及管理模式、业务模式的宏观管理问题，也是他们关心的内容。这里千万不可以把操作层遇到的非共性困难当作问题列入目标分析。

在分析影响的时候，要说明每个问题影响了谁，并且清晰、具体地列出来。不应该使用“客户”“公司管理层”这类指代不清晰的描述。

如果想说这个问题影响了客户，更合适的方法是说明具体影响了哪一类客户；如果想说这个问题影响了公司管理层，就应该把具体的部门、职位列出来；如果问题直接影响到总经理之类的最高管理层，为了写得更加文雅，可以使用“公司”一词来代替，毕竟影响了公司，也就是直接影响了总经理这样的最高管理层。

其次，要分析带来了什么影响、产生了什么样的后果，也就是完成目标场景描述。目标场景的描述主要针对项目相关的高层管理者，因此要从他们关注的层次来说明影响。对于高层管理者而言，他们更加重视经营层面的一些影响，所以产品经理需要合理推理，得出他们更加关注的信息。

最后，要合理推理、层次清晰，最好把整个推理过程呈现出来。

在定义好问题之后，就可以分析问题并确定解决方案了。在这个环节里，产品经理一定要记住：我们才是解决方案的专家，客户只是问题专家。

分析问题最常用的方法有两种：

鱼骨图法：这种方法认为，问题是由一系列子问题构成的。
问题现状树法：这种方法认为，问题是由一系列因果关系产生的。

上述两种方法使用时的注意事项：必须确保分析的问题和方法背后的假设是一致的。

在描述解决方案时，应该从宏观视角说明，并强调具体策略，以便客户高层理解。很多实践中会发现，策略化不足，就会导致方案写得比较空洞。

因为客户高层往往没有太多时间和充足耐心去看大篇幅内容，所以需要把这些内容提炼成一句话，对目标场景进行概述。概述的要点在于业务态和价值态，并用“措施 + 效果”的结构来描述。

这个大步骤最终要输出问题卡片文档。每张问题卡片只写一个问题场景；有多个问题场景，就写多张问题卡片。

每张问题卡片主要包括：

问题描述与评估：必填。应从业务事实以及产生的业务后果两个方面，客观描述问题。频率、厌恶程度、可替代性都可以选填。描述该问题发生的频率、产生的后果影响度，以及当前是否有替代解决方案，从而评估该问题的价值。
方案说明：必填。应从黑盒子或灰盒子视角阐述解决方案，帮助业务方构建解决方案的宏观认知。
预期结果：必填。用来说明当该解决方案投产后能达成的结果。
价值主张：选填。也就是所谓的一句话目标，通常可以作为需求规格说明书的小节标题，以措施加效果的格式编写。

然后是第二个大步骤，干性人识别。

项目是一场博弈，重要的是获得足够多的筹码，也就是需要找到关键的 Stakeholder。赢得足够的筹码，就可以赢得项目。

产品经理不可能获得所有筹码，但也不是识别出的关键干系人越多，效果就越好。

这个大步骤通常不能被跳过，因为它是从宏观角度抽象出项目和产品中最核心的需求。

首先，要根据目标识别关键干系人。干系人也被称为利益相关者、干系者或者影响者。干系人是指影响产品或受到产品影响的任何人、团体或者组织。这里说的影响，是指利益方面的影响；人、团体或组织，是指具体的人、部门或公司等；影响指的是该产品的活动和成果，也就是影响了产品的研发过程和设计结果。

根据目标识别干系人时，首先要收集客户的组织架构，然后根据目标和愿景来判断。在判断之前，先根据目标愿景把所有涉及的部门都标识出来。可以从公司角度、系统角度、业务流程角度来找干系人。这三个角度应该同时使用，并且相互交叉验证，避免遗漏干系人。

公司角度就是公司的客户、组织架构、合作伙伴。分析组织架构时，先梳理组织架构，再梳理架构下的员工。

系统角度就是回答 4 个问题：谁使用系统？谁查看系统？谁维护系统？用在什么地方？

业务流程角度就是回答两个问题：公司现有的主要业务流程是什么？在主要业务流程中都有谁参与？

把所有涉及的部门都标识出来之后，就要完成几个关键判断：

部门是否与目标直接相关。如果是的话，部门负责人为关键干系人。
相关部门是否有异地分支部门。如果是的话，分支部门负责人也是关键干系人。
是否存在资深副职负责人。如果是的话，这个副职负责人也属于关键干系人。

根据目标识别到关键干系人之后，还应该根据风险去识别其他干系人。如果项目会对一大批基层带来负面影响，应该把这些基层用户也标识为关键干系人，分析他们的主要诉求、担忧点，并做出相应的对策。但如果不存在这样的风险，一般不把基层用户列为关键干系人。

除此之外，还有那些具有一票否决权的评价者，这类人也算作关键干系人。如果系统的生命周期很长，技术实施存在高风险，那么上线之后的升级维护、适应性修改、运营工作也会很重要。这个时候，运营维护团队也会成为关键干系人。

最终要输出一个干系人类表文档，主要内容有以下字段：

类型：出资人和发起人通常没有必要列出来，因为目标分析的产物就是他们的核心关注点。使用者是未来会直接、间接使用系统的用户。评价者通常是财务、审计、法规、行业监管部门这些会提出验收标准的、通常拥有一票否决权的干系人。开发团队、维护团队、领域专家、技术专家等干系人，属于其他类。
名称：通常以职位的形式描述，也可能会以角色的形式描述。
说明：要简单阐述他为什么是关键或重要干系人。
相关度：相关度回答两个问题：项目与这个人直接相关吗？涉及这个人的利益或责任吗？可以使用高低两级评估，或高中低三级评估。
影响度：这个人对项目的方向验收有很强的影响力吗？可以使用高低两级评估，或者高中低三级评估。

但实际撰写文档时，相关度、影响度应该仅限于开发团队内部阅读，不应该直接提供给客户代表阅读，以免带来不必要的麻烦。

最后是第三个大步骤：干系人分析。对于一项业务是否要进行干系人分析，要看具体情况。

干系人分析的最佳应用场景是陌生且复杂的领域。但如果产品经理很熟悉这个领域，并且干系人比较少，那么干系人分析这项活动发挥的作用就很有限。

不过，先思考这个产品和谁有关，仍然是一个好的习惯，可以避免遗漏需求。

很多干系人分析实践都侧重于干系人的关注点，也就是正需求。但实际上，他们的阻力点，即负需求分析，也非常重要。想要执行好该任务，就要充分理解干系人负需求这个概念。

负需求实际上就是项目给干系人带来的负面影响。在进行干系人分析的时候，一定要从正负两个方面来考虑。

如果有多个关键干系人，需要优选代表，并明确其基本信息。

选择代表时，要注意其代表性和典型性。每个具体干系人在专业背景、职业经历、个人价值观、组织地位、工作经验等方面都存在一定特殊性，因此选出的一个或多个代表应该能够覆盖各种差异的干系人。

如果只选择一个或很少比例的人作为代表，就应该考虑典型性，也就是说，他们要能够代表较大比例的同类干系人。

确认好分析范围之后，就要了解他们的基本信息。

职业角色：主要包括该干系人在组织中的位置以及核心工作职责。了解这些信息，能够更好地理解他的诉求、关注点、阻力点，以及这些信息是基于什么样的角色来考虑的。
个人特点：主要包括专业背景、职业经历，以便了解其个人管理偏好和思考逻辑。
联络信息：主要包括联络方式、工作时间、沟通方式偏好，以便知道什么时间、什么形式的沟通最合适。
工作职责：即该干系人在工作中所负责的范围和承担的责任。

主要方法是查看行业资料、查看公司资料、进行业务访谈，或者进行现场观察。

在访谈干系人之前，应该根据分而治之的策略，先制定访谈提纲，也就是列出要访谈的内容清单。

分而治之常用的角度通常有三种：

按 KPI 分解：KPI 指标体系通常直接体现管理者的核心关注点，所以可以事先收集、归类，然后逐一切入，发现潜在的关注点和阻力点。
按工作主题分解：管理者通常会涉及多个不同的工作主题，事先梳理出被访谈对象的工作主题，以便访谈时能够实现分而治之。
按工作阶段分解：有些管理者的工作主题可能比较单一，这种时候就非常适合按工作阶段分解。

当然，在实际使用过程中，可以根据需要组合不同的分解结构，比如先按工作主题分出第一级，再按工作阶段分成第二级。

对于干系人而言，他们不仅希望系统解决某些问题，而且经常会担心系统带来一些负面影响。所以在分析干系人的关注点时，一定要注意：

他们希望系统解决什么问题，提供什么业务支持。
他们希望避免出现什么样的负面影响。

提问时通常先问业务，再问类型，最后问期望。

如果系统比较小、干系人不多，产品经理可以逐个调查干系人的期望。如果系统很大、干系人很多，就要先明确调查对象的优先级：首先围绕公司的主要业务找到干系人；在此基础上，找到和业务相关的高层决策人和中层管理人；最后再拓展到基层执行人。

不同干系人之间的期望存在差异。

高层决策人不实际操作业务，但会决定项目的投资方向、投资规模、分期规划等内容。所以，高层决策人评估项目主要看以下 3 点：

项目要能促进公司效率提高，并更好地服务用户。但即使产品能解决以上问题，高层决策人也不一定投资，因为资金对公司来说是宝贵的，只有项目创造的利益足够大，才值得投资。
如果高层决策人还有上级，那么不但需要考虑产品能否获利，还需要考虑产品的稳妥性，否则可能会影响其地位。所以高层决策人一般会选择较为保守的方案。
高层决策人也比较关注数据表现，以此评估投资价值，或向上级说明业绩。

针对高层决策人的特点，产品经理应该从价值角度思考产品能带来什么，强调产品的高价值，并设计出一些能表现业绩的统计功能。因为高层决策人不实际操作业务，所以关于系统如何使用，不适合向高层决策人询问。

中层管理人虽然不是高层决策人，但也可能影响决策，有时候甚至是决定性的影响。因为高层决策人在决定大方向时，也要听中层管理人的意见。如果中层管理人坚决反对，就可能影响决策。

高层决策人更关注用户用不用产品，中层管理人更关注如何提升销售额、提升服务质量等。同时，中层管理人也会关注如何管理员工、统计员工业绩之类的问题。

针对中层管理人的这些特点，产品经理一方面要强调产品的意义，另一方面也要强调如何帮助其完成业绩。在挖掘需求时，产品经理应该多挖掘管理性需求；对业务细节也可以问，但应该主要找基层执行人问。

产品经理对基层执行人做业务访谈的目的，是为了了解业务流程和日常问题。只有弄明白现有业务，才能设计新产品。

对基层执行人做访谈时，可能会出现几种情况：

基层执行人说不清自己的工作，这就要依赖产品经理的访谈技巧。
因为产品的价值在于提升工作效率，这有可能导致基层执行人失业，所以基层执行人可能会出现抵触或者贬低产品的情况。
基层执行人会提一些次要问题，但即使对这些问题做了修改，也没有办法大幅提升其工作效率。

针对上述基层执行人的特点，产品经理必须要有良好的沟通技巧，也要学会评估需求价值。对于价值不大的需求，必须甄别，不要盲目满足。

最终在描述分析结果时，应该包括两个部分：

干系人的关注点或担心点，即 why 的部分。写作时必须从业务角度写，同时以结果导向写，最终要能体现出价值。
相应的功能需求，即 what 的部分。

分析完干系人需求，还需要分析相关角色。相关角色不外乎三种人：

提出人：准确来说，是用户需求的提出人，而不是需求的传递人员。在公司里，任何人都可能是需求的提出人，但需求的提出人并不一定就是产品功能的使用人，需求背后要解决的痛点也并不一定是需求提出人的痛点。
使用人：也就是最终使用产品功能的人，是产品功能的终端用户。同样，需求的使用人也不一定是需求的提出人。
受影响人：受到产品功能和需求影响的人。需求的受影响人也不一定是产品的使用人。

所以，产品经理在进行需求分析时，一定要留意对受影响人的分析。有必要时，也要进行调研和访谈，从而更全面地理解问题并做出决策。

有时候，不同干系人的关注点会存在冲突，并且难以调和。所以，在分析出各个干系人的关注点之后，还需要识别这种冲突，并提出相应的解决方案。

在这个大步骤完成后，需要输出四个文档。

干系人档案文档

如果干系人比较少，关注点、阻力点也简单明确，可以裁掉这个文档，直接在干系人列表文档的说明栏里写明关注点和阻力点。

通常来说，每一张干系人档案只写一个干系人；有多个干系人，就写多张干系人档案。

档案首先要说明干系人的基本信息，包括名称、类别。这里的类别与干系人列表的类别相同。

相关度、影响度这两项同样只给开发团队看，不直接提供给客户代表。

职责是该干系人的工作职责要点，以便更好地理解他的关注点。

代表：如果有多个干系人，从中选择一个。

联系方式：以便找到他。所属角色：该干系人主要对应哪个系统角色。

然后要逐条写出该干系人的关注点（即正需求、阻力点（即负需求）；还可以考虑写出对应的功能需求。这部分要编号，以便跟踪。同时还要判断重要度，以便管理。

最后是备注，记录一些便于了解干系人的相关信息，比如专业背景、职业发展过程之类的。

每张干系人档案在需求规格说明书里作为一个小节，小节标题关键干系人名称来命名。

干系人工作职责简表

只有两个内容：一个是干系人，一个是干系人的对应职责。

干系人工作职责详表

要有以下几个内容：

代表：如果通过调查某个干系人得出表格中的内容，就应写出调查对象的信息，包括调查对象的姓名、职位、联系方式等，这样方便以后追溯信息来源。

工作职责：通过列出其工作职责，产品经理就可以挖掘产品要实现什么。

成功标准：工作职责明确了，也要明确成功标准。这些标准应该尽可能写全，因为这些成功标准也往往是新产品的成功标准。

参与工作：具体参与了什么工作也要列出来，未来进行权限设计时能用到。

这张表要在产品设计里不变迭代，以便理解干系人的工作。如果是给非专业人士看，最好把表中的“干系人”一词改成“用户”一词，因为“干系人”这个词不太常见。

对于比较小的系统，写干系人档案意义不大，所以可以不做。

干系人期望调查表：要有以下几个内容：

干系人名称：一般是干系人的职务名称。

工作职责和特点：一般一个职位有一份工作，但有时候一个职位可以有多份工作，产品经理就要在工作职责中分开描述。这里的特点是选填项，是对该干系人特点的描述。

干系人的期望：一般用几句话概括干系人的期望，主要包括需要实现线上化的业务，对效率和服务等方面的期望，但该期望不能深入到实现信息层面。

最好补充上他使用此系统的方式。