有些用户声称想要一个更便利功能，然而他们内心中真正渴望的，或许是节省时间，或许是减少跳转次数，甚至可能是无需自己动脑思考。于C端产品范畴里，需求分析的重点所在，并非仅仅记录用户所表述的内容，而是切实领会他们内心真正想要传达的涵义。此文会引领你步入“翻译用户语言”的实际操作场景，剖析C端需求的识别、澄清以及转化的整个过程，以便于你在众多繁杂的用户声音当中，能够明晰产品真正应当去做的事。

① 概念定义

需求是，用户于某种场景之下，未被兑成满足状态的，期望，其核心要素，能够被归纳成这样intellij idea cxf，“用户+场景+期望”。需求并非独立存在，而是依附于用户以及场景。场景呢，界定出了用户正在着手去完成的，具体任务，期望呢，则是展现出了行为背后的，深层动机与目的。

该核心聚焦于挖掘痛点的本质，而非预判既定方案时预先设定的方案，借助用户调研、行为观察等方式还原真情实景，关注问题层面的理性研讨而非方案层面的感性抒发，进而提炼出本质性痛点，于不同产品阶段，需求与业务之间的关系存有差异，从零至一的全新产品倾向于“需求驱动业务”的单向通路，而从—至—百的成熟产品则倾向于“需求与业务协同迭代”的动态均衡。

在产品整个生命周期里，需求分析始终贯穿其中。于概念期时，借助市场细分以及用户定位，从而确立核心需求；到了设计开发期，着重强调落地性，把抽象需求转变为可执行的产品描述；在上线至成长期，要一直持续验证需求满足度，并且收集迭代线索，以此来优化产品；处于成熟到运营期，将需求分析扩展至运营以及竞争策略方面，目的是创造更多商业价值；而在衰退期，需要通过研究市场需求趋势，进而预判战略调整方向。

② 需求分析三钻模型

一、【发散状】需求收集的阶段：进行调研，以扫荡式对原始用户诉求予以采集，①痛点的来源：包含直接以及间接的体验，从中捕捉用户的痛点。

于需求收集阶段之时，为能广泛地收集需求，可采用具备多维度及多渠道的方式开展，其中涵盖直接体验，也就是自身现身说法这种情况，同时还有间接体验，此情况就是他人的体验。针对用户侧，也就是C端而言，运用深度访谈之类的追问办法挖掘用户想法，借助用户真实反馈来定位关键问题；通过开展问卷调查获取量化数据；与KOL展开深度交流以此获得行业意见领袖洞察。在反馈渠道这一方面，要重视应用商店评论，以及产品反馈入口，还有社交平台等方面。

从产品方面，根据访客量、浏览量、以及页面浏览时长等行为数据（若存在）来反向推导需求，并且结合产品目标拆解、季度规划、还有版本进度节点等多种信息，从而全面收集需求，尽可能实现对各式各样可能需求情况的涵盖，暂时不去考虑需求的真假。

② 阶段性输出

在需求收集阶段的时候，应当把涵盖初始反馈的定性数据输出，这其中有用户原声，也就是用户是怎样表述的，还要输出包含可观察的数据，这是用户行为，即用户是如何去做的，与此同时，借助结构化字段，像编号、提出时间、用户名称以及用户基本信息，以此保障需求能够进行追溯以及管理。

二、【收敛】需求定义阶段的时候做聚类，把碎片化的问题抽象成为用户角色的场景故事，①先要构建用户角色，其过程是从具体实在的人过渡到抽象的标签集合。

构建用户角色，本质上是这样一个认知过程，是经历“从具体转向抽象，再从抽象回归到具体”的情形。在产品的起始阶段，当我们对于目标用户尚未明晰确定的时候，不要急切地去构建用户画像，而是能够先开展“用户特征标签化”的行动，也就是提取用户信息里的共性特点，将那些零散的用户信息归纳到几个基础性的维度之中。伴随用户调研不断深入，像是借助后期的调查问卷、A/B测试等用户研究方法去证实标签的有效性，并且逐步把它细化一番，进一步使用户角色得到完善补充。

标签体系（分类维度）参考如下：

② 讲述用户故事：建立用户旅程，场景化描述问题

C端产品场景化描述模板（可选择性删减）：

当①【用户角色】处于②【特定场景加上约束条件】之际，常常会因为③【关键触发事件】而产生某种情绪反应，虽说能够借助④【现有做法】去尝试予以解决，然而所面临的⑤【问题阻碍】却致使那种情绪得以强化，为了达成⑥【核心目标】，期望能够拥有⑦【理想方案】。

③ 阶段性输出

于需求定义阶段时，要以结构化方式展现用户角色，亦即完成从具象反馈朝着抽象角色的聚类转化，还有其场景故事，也就是用户旅程加上问题描述，这里还包含行为场景，场景描述也就是用户旅程关键节点，与之对应的问题阻碍及用户期望，与此同时，要洞察本质矛盾，也就是核心冲突，以此为后续解决方案设计给出明确方向。

三、【发散】，需求分析阶段，要做挖掘，从而找到真实需求，进而探索解决方向。

在前面经历的两个阶段之中，我们已然完成了需求收集，此需求收集存在第一层次，即记录了用户说话是什么样的方式、做事是怎样的行为，并且完成了需求初定义，也就是构建起了用户角色，还讲述了用户所属故事，然而仅仅只是做到这般却仍旧不够。医生若是仅仅只是听患者去描述症状之后就直接开药，那么极大概率会出现误诊的情况。同样的道理，我们在接下来的时候是需要进行更具深度层次的分析的。

在需求分析阶段，我们要先把注意力集中到具体场景上来进行问题挖掘，依据已经收集到的数据（用户角色/用户故事），采用拆解法等办法去解构表层需求（第二层次：挖掘出用户的行为动机以及真实目标），一方面去剖析用户所提出的“⑦ 【理想方案】”背后潜藏的真实需求（用户期望），另一方面去识别“④ 【现有做法】 ”当中存在的“⑤ 【问题阻碍】”，这一过程输出明确的问题定义，给后续分析提供聚焦方向。

在用户底层特质自洽之下挖掘出的问题，处于第三层次，即探究用户行为背后的人性底层逻辑当中。接下来，我们能够用人性维度，也就是心理、社会、文化等来解释问题根源。既要解读矛盾问题产生的缘由，也要分析现有方案失效的道理，最终提炼出超越具体场景的稳定行为规律，为预期的解决方案提供经得起时间考验的核心依据。

① 挖掘问题，即解构表层需求、洞察本质矛盾

用户想要什么 ≠ 真实需求

表面需求也就是显性需求，是那种用户直接陈述出来的功能请求，比如像“我要吃披萨”这样的表述。“解决方案”会因个人使用习惯偏见、对技术实现的误解以及特定场景临时变通而受影响，不能直接等同于真实需求，真实需求乃是驱动用户行为的核心痛点，是用户期望达成的本质目标，就像“我饿了，想吃好吃的”，汉堡能替代披萨满足需求，虽有明确意识的欲望，却因种种缘由可能尚未明确表达出来，潜在需求是用户尚未觉察但实际存在的需求，比如“吃东西会噎”，有吃的但没喝的，衍生需求是由主需求派生的关联需求，可能由政策/环境等外部因素驱动，比如吃汉堡时表示“我想看下饭剧”。

若处于用户笼统表示想要更多功能的情况，或负面反馈集中时，又或者在用户无法清晰表达自身需求之际，以及发现为竞品尚未覆盖的空白点之时，可刨根问底地询问“为什么”，此时拆解法常用于验证需求真实性。当出现用户旅程存在断点的状况，或者线上线下服务衔接不畅时，或者有不同的服务而多终端体验不一致时，又或者存在季节性需求变化时，以及用户活跃时段集中时，再或者不同生命周期用户需求冲突时，还有地域文化导致需求差异时，可按时空维度拆解问题。若是不同用户群体的需求呈现出显著分化的状况，又或者同一用户于不同场景下的诉求存在矛盾之际，能够特意强化问题里的对立要素从而暴露出核心矛盾。要是用户提出解决方案型需求，或者跟风竞品的功能需求，以及需要验证可能引发负面体验的需求之时，可以提出否定假设进而打破思维定式。

② 挖掘人性，即剖析用户“为什么成为这样的人”

由稳定的性格特质，与动态的环境交互编译而成的产物是人。每个用户的个体内在驱动因素，像性格特质、认知风格、负荷耐受度等，构成了行为决策的基础框架。而且用户行为，还持续受到外部环境影响，诸如社交网络、文化观念等外部环境塑造因素，两者共同阐释了“用户为什么成为这样的人”。

首先，用户行为的核心驱动力源于其内在心理特质（维度一）。其中，与生俱来的性格特点（像是否爱冒险），构成了决策风格的底层根基、基础；习惯性思考方式（偏好整体把握或者细节处理），对信息处理模式产生影响；还有在具体场景里的信息处理能力（对操作复杂度的耐受程度），这些因素一同塑造了用户最基础的行为逻辑与反应模式。

同时，用户行为深受多重外部环境因素极大地影响：于社会层面（维度二）而言，身份标签、社群影响力以及社会资源储备构成群体互动关键变量；在经济维度那里（维度三），风险承受能力、即时满足偏好和消费心理账户一同驱动着决策进程；于文化层面当中（维度四），用户潜意识里的理想形象、当下的人生阶段任务等所裹挟的价值观念，或者时代特征印记致使的价值冲突，反映出他们衡量事物的标准；而实际环境限制（维度五） ，涵盖时间分配习惯、空间依赖程度、社交场合行为差异以及设备使用习惯，为行为设定具体边界条件。这些外部的因素，跟内在的特质，彼此之间相互产生作用，一同对用户最终的行为表现起到决定作用。

③ 探索方案，寻找解决问题的方向而非答案

对于那种突破性创新的场景，像是去探索体验的上限，或者达成技术的跨越，“理想法/未来法/跨界法”能够助力走出固有的框架，凭借着前瞻的视角去探寻极致的可能性；在碰到系统优化需求的时候，“替代法/重组法/转移法”将焦点定在现实约束状况下的可行性改造上；当需求有待验证之际，“否定法/减法”保证了价值聚焦以及问题解决方向的正确性；要是想要探索增长的边界，能够运用“场景法”去延伸使用的边界以及实现环境的迁移，不断挖掘增长的机会。

④ 阶段性输出

需求分析阶段的逻辑，是一条从现象到本质的分析链路，围绕特定用户角色于相应场景中遭遇的问题阻碍，也就是表层情况，结合用户期望，去解构表层需求，剖析需求里面的本质，这本质指的是底层人性或者心理动因，还要探索解决的方向，即预期的解决方案，以此为后续产品方案设计提供具有系统化的需求洞察依据。

四、【收敛】需求初筛阶段：做减法，剔除伪需求和低价值机会

历经完成需求挖掘以及人性洞察的深度剖析之后，我们着手尝试从“问题空间”朝着“解决方案空间”进行跃迁，所产生的海量需求线索以及潜在机会，要借助系统化的评估框架来实施战略收敛。需求初筛阶段的核心任务在于，把前期挖掘出的各类需求放置到“痛点价值深度、解决可行性、潜在用户规模、商业价值”的四维决策框架里进行立体化筛选。不同于简单的需求排序，这一收敛过程借助结构化评估，在用户真实痛苦、企业解决能力以及商业可持续性之间寻觅最优的平衡点，剔除伪需求与低价值机会来评估，对解决方案展现经济性，并确保资源聚焦于真正值得解决的核心矛盾。这一过程是落实前一步分析成果，为后续方案设计划定清晰战略边界。

① 需求筛选的四大判断维度

要有效区分高优先级机会跟低价值需求，得通过评估下述这四个关键维度，这四个维度，既独立，又相互关联，首先得判断该需求对用户有多重要，也就是价值深度，其次要评估我们能不能有效解决，就是可行性，然后要分析受影响用户的范围，即规模，最后要衡量其带来的商业潜力，也就是商业价值，综合考量完这些后，我们就能做出更精准的资源配置决策。

判断一，该痛点对于用户来讲究竟有多“痛”，对于公司而言又有着何种程度的重要性呢，此为痛点价值深度。判断标准是，首先从用户的角度出发，去评估需求的紧迫性以及必要性，以此判断其是不是属于用户的核心痛点，接着衡量需求的覆盖面以及长期影响，其次从公司的角度来看，评估需求是否契合用户价值原则以及公司战略。

判断二：这个痛点能不能被有效的解决？我们有没有能力去解决它？（此为痛点解决可行性）。判断的步骤是：首先去瞧瞧市场上面有没有解决方案，要是没有成熟的方案的话那就分析一下根本原因，然后再评估自身是不是具备解决所需要的资源或者独特的优势？

判断三：有多大的潜在用户群体正受此痛点困扰呢？（潜在用户规模）判断方法：借助目标用户画像去定义受此痛点影响的群体，运用数据推演、调研采样等方式来量化规模，可试着综合数据估算出“可触达且可能使用”解决方案的市场用户规模。

判断四：目标用户群体当中具备该痛点的，其变现能力怎样呢？（这是关于潜在用户商业价值的）。判断维度有三个，分别要从支付能力、支付意愿、规模化潜力这三个方面，去评估目标群体的长期商业价值。

综合决策：通过交叉分析这四个维度，我们能够清晰识别，

痛点所具备的价值程度高，这种价值体现在深度和广度两个方面，其解决的可行性很强，涉及的用户规模庞大，所蕴含的商业价值极高，面对此类情况需全力投入。这属于理想机会。

若是痛点价值处于较低水平，或者解决该痛点呈现不可行的状况，又甚或是用户数量极为稀少，亦或是商业价值显得微薄；那么需要明确地将其予以剔除，也就是那些低价值的机会。

3）但现实中多数机会处于中间地带，需要权衡与取舍：

② 阶段性输出

在前期需求分析所获成果的基础上，依据四大判断维度展开操作，对需求实施初步筛选，进而输出一份分析报告，此报告涵盖用户角色、问题阻碍（表层）、用户期望、需求本质（底层）、解决方案（预期）等核心要素，同时明确标注伪需求（×）以及低价值机会（×），以此保证后续资源能够集中于真实且具备高价值的需求机会。

五、【发散】，需求完善这个阶段：呢，要做那件被叫做加法的事，进而去建立一个全渠道需求的那个池子 ①，六大需求有着属于它们的来源。

按这样的图示，于需求收集阶段，依据痛点原有的来源，增添来自竞争方面、同事方面、老板方面的来源。

为什么要完善需求来源？

于完成用户需求的分析以及初筛之后，我们得把视野予以扩展，伸展至更为广阔的需求收集维度。产品的成功，可不单单取决于对用户痛点的精准把握，还需要去协调内外部多方的诉求以及资源。仅仅单一的用户视角，极有可能忽略市场竞争力、技术可行性等关键维度，进而致使决策出现偏差。

全渠道需求收集体系的建立，其核心意义在于搭建多维度的产品决策体系。其中，竞品分析涵盖关注竞争对手所推出的新产品、新服务以及新功能，剖析对手的优势市场与薄弱环节等，借此有可能发觉差异化机会，进而构建竞争壁垒。还要提前协调各部门诉求，像技术/运营部门的限制性需求，从源头提升方案的可行性，防止设计出“空中楼阁”。更为关键的是，老板侧需求常常蕴含对政策变化、市场格局的前瞻判断（说得不客气些，也可能老板就是出于自身想法……）。这种通过全渠道进行需求收集的方式，能够起到避免片面决策的作用，进而打造出产品解决方案，此方案真正具备市场竞争力，而且还能满足用户体验，也就是满足发薪人体验。

② 阶段性输出

于原本用户侧、产品侧的需求源头之上，增添竞争侧的需求源头，此竞争侧涵盖市场趋势分析、竞品动态这些方面，还要增加同事侧的需求源头，这包括运营活动、技术架构、市场策略这些内容，并且要添加老板侧的需求源头，即战略规划背景及目标方面，以此形成多维需求清单，里面包含外部竞争分析、内部协作诉求以及战略导向，从而为后续的需求评估、产品规划给出全面的决策依据。

六、【收敛】，处于需求排序阶段，要去做权衡，优先考量解决高频刚需的问题，还要解决高价值的核心痛点。

完成需求收集以及分析之后，我们得去建立那种动态化的需求优先级评估机制，需求分析贯穿整一个产品生命周期呀，所以需求排序可不是静态的数学计算呢，而是要依据生命周期阶段，考虑市场销售层面，进而持续调整的决策体系。

不同场景的权重调整建议

在导入期，也就是培养市場的阶段时候，首要目标是去解决核心种种痛点，力求保证基础应有的功能能够正常得以使用,所以在此期间，用户所承载的价值以及战略所呈现的契合度，二者的相较比重相对而言是比较高的，需要迅速去验证这款产品在市场方面的匹配程度。

步入成长期，也就是经历体验并扩宽市场的那个阶段，我们会遭遇诸多竞争对手，用户可选择的项目变多了，这便迫使我们既要把产品本身的功能质量精心打磨好，又要尽可能地去扩大功能所覆盖的范围，将自身核心竞争优势充分发挥出来，所以在平衡用户价值与公司价值之际，要关注技术可行性来为功能扩展提供支撑。

发展至了成熟期，也就是保持市占率以及运营的阶段，我们需要持续不断地细细打磨产品体验，优先去满足市场运营方面的需求，一步步地去构建产品技术壁垒，而在这个时候，公司价值以及技术可行性变成了关键指标。

在衰退期，也就是减法加上开拓新市场的阶段，我们要降低成本提高效率，把那些没有意义的低频功能给去除掉，更加专注于业务的深度，与此同时，还要进行产品技术创新，拓展产品的方向，所以战略契合度对应的权重就会被相应提高。

这种动态权重机制确保资源始终精准投向最具阶段价值的需求。

① 战略契合度 （20%）

将战略契合度评估得来的需求与之公司战略目标的对齐程度进行判断，这是资源作分配时候最高优先级方面的判断依据，此维度能保障所有开发投入皆服务于核心业务目标，在需求刚开始进行筛选的阶段，我们针对用户痛点的解决跟公司战略之间的契合度做过判断，其评估标准是这样的：

核心聚焦（优先开发）：它是符合产品核心价值主张的，能够直接支撑当前战略目标，其基础分是20分；远期储备（暂缓开发）：这是符合长期规划却并非现阶段重点的，需要定期重新评估优先级，基础分12分；风险规避（不予开发）：此为偏离主营业务方向的，存在政策或战略风险，基础分0分。

在基础赋分之外，引入战略系数当作动态调节因子，然而每个公司因自身业务特点各异，自定义项目的等级划分标准不一样，战略系数值能够相应改变。要是需求属于那种战略卡点项目，会给战略系数赋1.2；要是需求属于通常的业务项目，就把战略系数赋为1.0；要是需求属于有争议的项目，为了降权控制风险，战略系数赋0.8。

战略契合度权重的最终得分 = 基础分 * 战略系数

② 用户价值 （20%）

方法一：用户分层（5%）

用户价值的原则是，优先予以百分之八十主流用户这儿所说的核心用户以满足，所满足的是核心需求，而并非是给予百分之二十小众或者边缘需求这儿指的边缘用户以满足呀。

核心用户需求的满足程度，乘以4分，加上，边缘用户需求的满足程度，乘以1分，得出的结果是用户分层得分：

方法二：KANO 模型反映用户满意度（15%）

由狩野纪昭教授所提出的KANO模型，它是以对用户需求对于其满意度的影响作出剖析作为基础的，该模型体现出了产品性能与用户满意之间的并非线性的那么一种关系。KANO模型把需求划分成五个维度：

1. 基本需求：将此需求予以提供，用户满意度就不会得到提升，要是不提供此需求，用户满意度便会大幅度下降。2. 期望需求：把此需求进行提供，用户满意度得以提升，若不提供此需求，用户满意度会下降。3. 兴奋需求：处在用户没想到却喜欢的这种情况，当提供此需求， 用户满意度会大幅度提升，若不提供此需求，用户满意度不会下降。4. 无差异需求：不管是提供此需求，还是不提供此需求，用户满意度都不会产生改变。5. 反向需求：当提供此需求时，用户满意度反倒会下降。

KANO模型的数据源自问卷调研抑或用户访谈，理论而言，用户样本得具备代表性，并且样本数量不能过于少。针对于某一种需求，调研问题需从此种需求正反两个维度予以设计，也就是提供之时以及不提供之时的满意程度等级。而满意程度通常划分成五个等级，分别是非常满意，还有满意也就是理应如此，再者是无所谓等同于一般，另外是不满意即勉强接受，最后是很不满意。把调研结果汇聚统计成如下表格所示：

该需求的 KANO 模型结果中，占比最高的类型就是它。把“无差异需求和反向需求”去除掉之后，对于剩下的三类需求，其优先级排序规则是这样的：基本型需求，给它赋予 5 分；期望型需求，赋予 3 分；兴奋型需求，赋予 1 分。

用户价值权重的最终获取的分数，等于，用户分层得到的分数，乘以，占比为百分之五除以百分之二十的数值，加上，KANO模型所得到的分数，乘以，占比为百分之十五除以百分之二十的数目。

③ 公司价值 （25%）

方法一：RICE模型（10%）

一）Reach，它指的是覆盖用户数，是依照实际用户行为数据来进行估算的，也就是受影响的用户规模。

2）（影响强度）：评估需求对用户或业务目标的潜在影响

3）（信心指数），它是用于衡量团队对于Reach的信心程度的，同时也是用于衡量团队对于评估这一行为的信心程度的。

4）（投入成本）：估算完成需求或项目时，团队里所有成员，包括产品、设计、开发、测试等人员，所需要投入的总时间，只要单位统一就行，比如“人/月”或者“人/天”。

先计算原始的RICE模型得分，该得分等于（Reach乘以某数再乘以某数）除以某数。之后，运用分段映射法，把原始RICE分区间转化为标准化得分，此标准化得分为5分制，如下假设所示的图那样。

方法二：投入产出分析（15%）

收益维度表示能赚多少钱：

直接收益层面说的增收或者降本，此功能上线之后，究竟能够比往常多卖出多少货物，或者多收取多少会员费，又能够节省多少钱，这块在通常打分里是从1分到5分 的范围 ，间接收益层面来说指的是如考核里NPS或者体现效率、市占率、以及壁垒等方面，现在想问的是用户是不是会更倾向于推荐我们，内部工作效率有没有可能提升到一倍，能不能够帮助我们把市场位置稳固住，是否起到辅助构建竞争壁垒的作用，这属于加分项，每一项可为加5分。

成本维度表示要花多少钱：

用在人力、资源以及营销方面的明面成本问的是，开发究竟需要多少人员intellij idea cxf，所花费的资金是多少，耗费的时间又有多久，实体硬件生产所需要的成本是多少，进行产品推广需要投入多少广告费用，范围大致落在从一到五分之间，隐性成本包含延期损失以及失败补救，问的是要是开展此项有哪些重要功能将会被推迟，会造成何种损失，倘若万一失败了该如何应对，需要赔付的资金又是多少，属于减分项，每项扣减五分。

需求ROI得分，等于，总收益分，减去，总成本分，同时，存在，灵活加减分的情况。

按5分制，直接收益与明面成本被赋予基本分：直接收益预估情况是，其越高，收益基本分就越高，且越高越好；明面成本预估情况为，其越高，成本基本分越高，然而越高越不好。间接收益以及隐性成本通过加减分形式来赋分，其中加减分项的分值能够自定义：要是需求显著提高NPS，或者能建立技术壁垒，又或者竞品存在同类功能等，那么每项会加自定义的5分，要是需求推迟了其他重要需求，或者技术风险颇大，又或者需额外硬件投入等，那么每项会减自定义的5分。

公司价值权重的最终得分，等于，（ＲＩＣＥ模型得分，乘以，占比１０％除以２５％），加上，（需求ＲＯＩ得分，乘以，占比１５％除以２５％）。

④ 需求来源 （10%）

需求来源之评估，此乃经由追溯需求所提出之相关方，以及其背景动因，借助这般方式去验证需求的真实性，这更是关键的那个维度，而它是用于判定需求背后所蕴含的驱动逻辑的。

若凭借直接用户反馈、借助行为数据验证，进而判定某用户需求属于高频痛点，那么基础分是5分 ；若该需求契合公司战略规划，同时满足政策合规要求，或者顺应重大市场变化趋势，这般来讲基础分是4分 ；若能满足业务方需求，并且有资源予以支持，如此基础分是3分 ；若通过竞品分析，发觉与对手的体验存在显著差距，且尚存差异化空间，这样基础分是2分 ；若满足内部规划需求，契合产品路线图，基础分即为1分。

除了基础评分因各司业务不同而有差异外，我们引入可信度系数当作动态调节因子，来对需求真实性做加权处理，经过数据验证的需求，赋予强化其的1􀆰2的系数，逻辑合理自身可成立但没有数据可以用来支撑的要求，则维持1􀆰0的基准系数，存在明显能够被质疑的点的需求，就凭借0􀆰8的降权系数来控制风险。灵活的系数处理在需求真实性与执行可行性之间构建起动态的平衡机制。

需求来源权重的最终得分 = 基础分 * 可信度系数

⑤ 技术可行性 （20%）

技术可行性所指的是，对需求在当下现有技术状况下能否实现进行评估，它涵盖着开发难度、资源投入以及风险控制这三个核心维度，此指标会对需求落地的成功率还有时间成本产生直接影响，倘若开发方面存在越多不确定因素，那么评估所获得的分数便会相应降低。

技术成熟度（涵盖现有或需研发的状况）以及第三方依赖程度用来界定开发难度，要是现有技术能够直接拿来复用，就赋予5分，要是需要适度开展研发工作，那就赋予3分，要是需要取得重大的技术突破，那便赋予1分。硬件、云资源等来指代资源投入所涉及的成本，要是不需要额外的资源，赋予5分，要是需要购买基础资源（像云资源这类），赋予3分，要是需要有着专项的预算，赋予1分。技术不确定性以及工期延误风险被称作风险等级，要是预估不存在风险，赋予5分，要是预估风险能得到掌控，赋予3分，要是预估存在高风险，像新技术未曾经过验证这种情况，赋予1分。

技术可行性权重的最终得分 = 三维度得分总和

⑥ 需求依赖 （5%）

需求依赖所指的是，功能需求之间存在的先后制约关系，它是用于确定开发时序的关键维度，依赖关系能够被分为三类。

能够展现功能的需求属于后置需求，基础3分；必须做到前面就能出现真实的数据需求便是前置数据如分数一般为5分；如果这个不是可看就行那么这个前置需要有独立行就变成了并行需求，基础分数1分需求如能够做到多一种模式支持这种情况一般是后置需求。

通常情况下，被包含前置需求的所要具备之优先级往往比那些排在后面的后置需求的优先级要更高一些，前置需求在占据极其重要的地位以及所必需具备的紧迫性方面均高于后置需求在这两方面所呈现出来的地步。产品经理负责去标记注明初始阶段的依赖关系，也就是赋予其基础方面的分数，随后就需要技术领域肩负起重责的负责人，或者是产品经理其自身来对依赖所处之强度予以确认，也就是赋予其表明依赖程度的系数：

强依赖（系数0.3）：那是必须要优先来进行开发的前置需求，要是不实现的话就会阻塞多个核心功能呢，比如得先有用户系统之后才能够提供付费功能。中度依赖（系数0.1）：这种是可以并行去开发的不过需要进行协调，会对部分功能体验造成影响，就像先得有商品详情页，而后才去设计推荐系统。弱依赖/无依赖（系数0）：属于独立能够开发的功能，仅仅是对体验进行优化并没有实质的阻塞情况，例如界面主题切换。

依赖权重的最终得分 = 基础分 * (1 + 依赖系数)

⑦ 阶段性输出

采用加权方式来计算总分，其中，战略契合度所占比例为20%，用户价值所占比例为20%，还有需求依赖所占比例为5%，以此类推，最终通过特定运算得出总分。

依据不同需要的加权所得分数，划分出优先级分段范围（记其为P0，P1…）。要是某一项属于“战略必须”，那就直接确定为P0，要是某一项技术风险过高，那么总分能够根据情况扣减掉百分之二十。

结语

全流程的需求分析完毕之后，要把用户需求转变成产品需求（也就是产品语言，具体指产品功能列表），还得跟相关团队开展需求评审。需求评审一般会涉及多方面人员，以此来保证功能规划具备合理性以及可行性。

由产品团队主导整个需求以及功能的规划，于评审期间要阐述产品功能设计背后所蕴含的逻辑，也就是需求展开分析的过程，要讲明白需求的来源，要说明为何要做这个需求，要诠释这款需求具备怎样的意义，要讲清楚此需求需要借助哪些产品功能展开配合，要指出同类的竞品有没有该功能，要阐述为何这个需求的优先级会比较高。

研发团队要从技术实现方面考量功能并加以评估，需判断技术可行性如何，分析开发难度怎样，还要考量时间成本等情况，请标点符号算呀。

运营团队，要从自身角度提出由用户需求转化而来的产品功能，看看它对用户增长、留存以及商业变现会有怎样的影响，还有价值点所在：市场团队，同样需从自身角度提出这类产品功能，分析其对用户增长、留存和商业变现的影响与价值点。需求评审终于结束了，然后要给出一个需求分析的最终结论，到底是做还是不做，要是做的话，具体是什么时候做，又需要多少投入等。

以上，需求分析的流程用于C端，其方法只是行业实践里，那如同冰山一角般微小呈现出来的部分，仅供参考学习。

如有侵权请联系删除！