项目需求分析怎么写「产品需求分析总结」

调研结束，很多小白会直接就业务需求给出解决方案，这是一个很大的误区：业务往往是先提出解决方案、产品经理再去挖掘需求产生的背景，如果我们在不加以分析后直接给出解决方案，容易使人钻进一个点中只考虑当下的问题、也会受到初始方案的一些错误引导。
实际业务中，业务提供的思路不一定是最优解，且不同功能模块间的操作是联动的、修改某一操作可能会给关联的其他功能带来影响，等到测试上线才意识到出现问题。为了避免这种情况，产品经理需要在充分了解产品及业务的前提下多考虑整体性及拓展性。
在误区背后，我梳理了以下判断方法，可以帮助你再更清晰的了解业务后分析需求、得到最优解。

文章插图

一、构建用户画像1. 什么是用户画像
简而言之，你的目标用户是一群有着很多共同特征的人，用户画像是根据这群人的社会属性、地域分布、行为动机等信息抽象出的用户模型。所以构建用户画像的核心是给一类用户“打标签”，以标签的形式将此类用户的主要特征抽象出来。
2. 为什么要构建用户画像
产品的使用者不一定是需求的提出者。产品经理需要将调研收集到的需求对应到具体的人群类型上，从使用者的角度来思考需求的最优解。以做一个后台的CRM系统来说，我们面对的角色有一线销售人员、组长、经理、老板等，每个角色对系统提出了不同的需求。
一线人员说“现在跟进客户有点麻烦，我认为应该把这个功能做成这样……”，老板说“能不能把员工每天的工作人效做一个汇总的页面给我看？”
通过构建用户画像，产品经理可以定位用户的使用目标，这在需求分析中起着至关重要的作用。在上述场景中一线人员的目标是提高工作效率、更快的触达客户，老板的目标是更好的进行向下管理，根据这一前提，我们能找到各种优化点以达到他们的目标。
产品在与目标用户建立连接关系过程中，我们尝试以用户所处的阶段看待产品，更有利于形成对用户的同理心。
3. 怎样构建用户画像【项目需求分析怎么写「产品需求分析总结」】构建用户画像首先要树立出用户的整体轮廓，对这个用户的大执行想做一个初步判断；再将其使用目的及其他影响因素补充到用户画像中，补充细节可以辅助产品经理更深刻的理解用户。
1）. 初步形象
初步形象是人物的轮廓，包括角色、职位、人口属性（性别、年龄、教育情况）、大致需求等。这里需要注意的是，方法不是规则，对不同产品来说需要列举的内容是不同的，是要在项目实际需求背景中，列举用户属性中会对产品的使用产生影响的点。
2）. 使用的动机
了解用户使用动机是在用户画像构建过程中的必要步骤。行为动机包括目标、用户路径、起到推动作用的元素、起到阻碍作用的元素和可能触动用户的点。
通俗来讲，用户为什么要使用你的产品，使用路径是怎样的，用户使用你的产品来解决问题跟其他途径比起来优势在哪，优化哪些部分更能触动用户，这些都是在分析用户的行为与动机时需要考虑到的。
3）. 可能受到的影响
用户在使用产品时主要会受两个方面的影响——内在影响和外在影响。内在影响可能是产品的交互体验差、某个功能不满足预期或者无法解决实际需求等；外在影响是用户要受到不同外界环境和人员的影响。
例如，公司要引入一款新的内部管理系统，那么会涉及到公司员工（主要使用者）、公司老板（决策者）、公司合伙人（共同决策）、财务人员（购买产品）等人员。我们要分析不同角色对最终决策的影响，就要对不同角色建立用户画像，了解不同角色使用产品需要解决什么样的问题。
二、梳理使用场景梳理场景是进行需求分析的重中之重，也是比较容易被忽视的一项操作。了解好场景才会对整体流程的脉络有一个更清晰的认知、不会造成需求的遗漏。与其在功能设计上摸着石头过河，不如在需求分析阶段打好场景梳理的基础。
以CRM产品举例，运营部门新增了一条业务审批流程，并要求该功能放在“客户”维度下让销售使用，但是在实际业务场景中，该审批是基于“该客户已有商机”的前提条件下发起的，所以在商机维度添加审批流程更为合理。
1. 梳理场景的思路是什么呢？
在整体上拆成“角色”、“使用阶段/业务阶段”、“场景描述”、“痛点”、“解决方案”五个字段。我们要明确进行这项业务活动的角色是谁，他处于整个场景中的哪个阶段，具体描述他在这个阶段中做了哪些事情、是如何去做的，他在做这件事情的时候遇到了哪些影响效率、体验不好的点。
在步骤上，前四个字段解决完成后先不要急着去想解决方案，最好的方式是把这个需求所涉及到的全部阶段的场景列清楚后、再回过头来去思考解决方案，这样可以保证思路是前后连贯的、不会局限于一个场景去解决问题。
2. 如何进行全面的场景描述？
管理学中有一些常见的分析方法可以使用在场景描述中。比如对选定的项目、步骤或操作，都要从四个方面提出思考。同样的，我们可以使用这个方法在日常工作中对业务场景进行梳理。

对象（Who）——这里包含是谁在做这件事？他在做这件事的时候涉及到哪些人？这里是为了明确这个场景所关联的干系人。
场所（Where）——他是在哪里做的这件事？为什么偏偏要在这个地方干？换个地方行不行？如果需要的话，可以在需求分析时考虑用户当前会受到哪些外界环境的影响；
时间（When）——这个场景是在什么时候做的？用户为什么会在这个时候干？能不能在其他时候干？如果目前的场景前置或后置，对流程会产生什么影响？在这里需要考虑，当前这个操作/场景放在这里的合理性。
方式（How）——用户目前是怎样做的？为什么用这种方法来干？有时候方法一改，全局就会改变，可以思考有没有更好的方式来解决当前问题。

根据调研结论来撰写场景故事，把用户某个特定时刻，可能会出现的行为、心理活动、具体的需求，解决方案叙事出来。其目的就是提高对用户可能身处场景的理解，这样要把用户心理状态描述出来，才会最终会变成产品中的行为。
三、总结通过以上两种方式，可以对需求进行理解并形象化用户之间、用户本身的诉求、用户与外界物理环境之间的一些显著特征。
接下来产品要做的是根据价值与可行性来判断需求的优先级，在经过上述的一系列思考与整理后，接下来就到了具体的落地执行阶段，这里可能会涉及到对需求进行最终整理，将这些内容汇总成一份可以呈现的方案，最后进行原型设计。
这篇文章就写到这里，欢迎在互联网公司工作的、想进入互联网行业的朋友来交流沟通，一起学习进步。