从需求分析到需求设计的怪谈

需求分析是产品经理日常工作内容之一。本文分享了需求分析到产品方案的过程和需要注意的问题点，供大家参考学习。

本篇文章大约有6000字，主要围绕3个点展开：

一、需求评估：即从海量的需求中如何抉择做哪些需求

二、需求方案：即从方案前期如何规避风险，减少方案修改成本

三、需求设计小课堂：即从产品设计、数据库、API层面说一下产品设计的注意事项与技术知识

正文开始，enjoy

一、需求评估之三步走

第一步：需求分析

1、还原场景

警匪片中，警察破案惯用手法之一，根据现场痕迹，还原罪犯作案过程，然后推测后续罪犯的动机。那类比到产品上来就是：在什么环境下，什么人做什么事，他为什么做这件事，最终产生的价值是什么等等。其中环境、人、行为、痛点收益指：

• 环境：可以是仓库、办公室等
• 人：什么身份、岗位、收入、语言、国家等
• 行为：用户做什么事，操作流程是怎样的
• 痛点&收益：在做这件事的过程中，用户遇到了什么困难点；以及他预期想要获得的结果或收益是怎么样的

2、十万个为什么

通过需求分析后，如果遇到有不理解的内容/或者似是而非/或者大概也许可能是这样/或者感觉我以为我理解了/或者写的有歧义的，那这种就需要警惕了，多追问几个为什么，可能就能挖掘到需求的本质

第二步：需求评估

需求分析完成后，怎么定义这个需求要不要做，也可以按照几个方法来

1、产品定位

看需求是否符合我们产品定位，例如某出海电商业务，应该以本土需求为主，结合处理跨境供应链业务（跨境供应链无非就生产、运输、仓储、报清关、配送等环节的处理）

2、战略定位

例如目前产品的北极星指标是日活和营收，那就看这个功能能否为日活和营收添砖加瓦

3、产品阶段

产品阶段指种子期>成长期>成熟期>衰退期。这个只能根据当前产品所出阶段，仁者见仁，智者见智了。

4、目标客户

这个功能提出的用户是不是我们的目标客户。例如我们的目标用户是本土发货且相对精铺/精品/品牌的客户，那铺货用户提出的需求，这种可能就要谨慎决策

5、需求价值

这个可以围绕广度（即是否通用功能，覆盖用户有多大？）、频率（注意不是反馈频率，而是用户的使用频率）、需要程度（刚需还是非刚需，没有这个功能就跑路吗？）、趋势（反馈的用户量有多少，是呈上升还是下降趋势）、最后一个就是成本（做这个大概要多少人力，与上面哪些点带来的价值是否呈正比）

第三步：需求优先级定义

使用kano模型+四象限法则+覆盖用户范围基本就可以很好的定义需求优先级了。

1、Kano模型：

基本型需求（底线需求）

定义：用户认为产品 “必须有” 的功能。如果产品缺少这些功能，用户会极度不满意甚至流失；但当产品具备这些功能时，顾客也不会因此而特别满意，他们会认为这是理所当然的。

示例：对于一部手机来说，能够正常拨打电话和发送短信就是基本型需求。如果手机无法打电话，用户肯定会非常不满意；但仅仅能打电话，用户也不会觉得这有什么值得称赞的，因为这是手机最基本的功能。

期望型需求（越多越好）

定义：期望型需求与用户的满意度呈线性关系。产品提供的这些功能越多、越好，用户就越满意；反之，用户的满意度就会降低。

示例：手机的电池续航时间。如果手机的电池续航时间长，用户会比较满意；如果续航时间短，用户的满意度就会下降。而且用户对于电池续航时间往往有一定的期望，比如希望能满足一周的正常使用。

兴奋型需求（惊喜需求）

定义：这些是用户意想不到的功能，能够给用户带来惊喜，使用户的满意度大幅提升。即使产品没有这些功能，用户也不会不满意，因为在用户认知范围内并没有这些功能的存在

示例：例如天马行空一点，如果现在手机能实现太阳能充电，这个可能并没有在我们的预期内，当我们发现可以太阳能快充时，再也不会为手机没电感到烦恼，然后哇一声，太牛了（如果有老板感兴趣这个项目，请务必联系我…狗头.jpg）

无差异型需求（够用就好）

定义：用户对这类功能并不在意，这些功能的有无不会影响用户的满意度。

示例：例如某果，手机摄像头是三个横着放还是交叉放，对于大部分用户来说，这个并不会对他们使用手机的体验和满意度产生任何影响

反向型需求

定义：这类需求是指用户不希望产品具有的。如果产品提供了这些功能，反而会导致顾客满意度下降。

示例：例如现在APP满天飞的内置广告，用户并不感兴趣，但是还无法关闭（想关闭要当股东的…），这会让用户感到厌烦，降低满意度。

2、四象限法则：

重要且紧急（危机任务）、重要但不紧急（战略任务）、紧急但不重要（干扰任务）、不重要且不紧急（浪费时间任务）

二、需求方案之规避风险五步法

第一步：需求计划制定

一般需求在前期大概知道是做什么，同时也要根据大概知道的内容制定一个最晚评审日期，那根据这个日期往前倒排计划，分别制定需求拆解、竞品调研、需求框架、需求设计、需求预审等各个节点的时间，然后根据计划往前推进

第二步：需求拆解

首先获取需求中的概念与流程，对于需求整体内容先建立认知

对概念和流程有认知后，然后对需求进行拆解，看下可能涉及哪些功能内容，粗略的写一个功能内容&功能影响点

第三步：竞品调研

需求拆解完成后，大概知道要做什么东西了，此时可以站在前人的肩膀上做设计，即进行竞品调研，竞品调研一定带着目的去进行，把竞品相关的截图和流程梳理清楚，同时在调研的过程中思考下对方为什么这样设计，优缺点分别是什么。最后所有竞品调研完成后，输出一个总的调研结论

第四步：需求清单

通过需求拆解与竞品调研，基本可以确认我们的设计方案，此时第一步应该是整理该需求的影响点，最好是根据系统页面挨个看，确认影响点后罗列详细影响点&解决方案，形成需求清单

第五步：需求方案确认

有需求清单后，可以针对相关内容粗略的画个草图说明设计方案，如果有需要可以拉个正式会议与其他部门或领导快速对齐；如果感觉无风险，可以直接开工设计或者单独拉群后将设计内容发出，让大家看下是否有疑问或建议后在开工

三、需求设计小课堂

设计寄语

请牢记需求方案是写给其他小伙伴看的，其他人看的好才是真的好

设计思路

1、启动A计划

前期通过脑海或者草稿纸进行思路构建，当整体内容考虑清楚后，则可以启动下一步动作

2、你先别急，请继续构建B++计划

不要满足刚开始的创意，趁思路活跃时创造或探索更多的备选方案，太早喜欢你的创意会阻止你创造和探索更多的方案

3、方案抉择

当穷尽认知内的方案后，可以分析根据每个方案的可行性&优劣性，挑选出你认为比较好的方案内容

4、曝光计划

当认为方案左右为难时或者需要确认时，迅速曝光方案，从而寻求其他小伙伴或其他部门的反馈

设计注意事项、数据库&API知识

请牢记“增删改查显算传&数据库&接口&异常”。详细解释如下：

增：即新增、创建、添加等

定义

一般指内容的从无到有，即新增内容

注意事项

1、表单内容

1.1）字段：考虑字段类型（文本框、下拉等）、格式、数据源、上下限、默认值、唯一值（账号唯一/全局唯一/某条件下唯一）、是否需要排序、字段之间联动、系统生成字段值的编码规则（例如文本+随机数…）等

1.2）图片/视频：考虑尺寸、大小、格式、比例等

2、校验

2.1）校验时点：离焦校验、实时校验、点击某控件后校验等等

2.2）校验内容：

2.2.1）必填校验：必填项是否为空

2.2.2）异常校验：是否有关联引用数据，如果有被引用的数据不存在/过期/状态不符合等如何处理；是否有添加数量上限，如果有超过如何处理

数据库（SQL）语句

数据库层面对应语句就是Insert into，代表插入/新增数据。例如：要向数据库表名为“t_product”表中插入一条新的产品数据，表中有product_id（产品id）、product_name等字段，则SQL语句为：

Insert into t_product (product_id, product_name) values (001, ‘这是产品名称’)

API体现

1、请求方法：一般使用POST方法（即向服务器提交数据），通常用于提交表单

2、定义接口路径，例如api/addProduct

3、请求格式：一般是JSON对象，例如{product_id:001,product_name:“这是产品名称”}

删：即删除

定义

一般指内容的从有到无，跟增刚好相反

注意事项

1、删除方式：逻辑删除or物理删除？（逻辑删除一般指假删，即通过标记实现；物理删除为真删，即从数据库删除，这种删除是不可恢复的）

2、删除一般是不可逆且高危操作，注意增加二次确认弹窗

数据库（SQL）语句

数据库层面对应语句就是delete from，代表删除数据。例如：要从数据库表名为“t_product”表中删除product_id=001的数据，则SQL语句为：

delete from t_product where product_id = 001;

API体现

1、请求方法：POST（HTTP通信规则中标准为Delete方法为删除数据）

2、定义接口路径，例如api/deleteProduct

3、请求格式：例如上述案例可以只传ID到服务器，就可以使用form-data格式，例如productId:001（其实from data 和json区别并不大，都是键值对的格式，即key:value）

改：即编辑、修改、调整等

定义

一般指内容的从1到N，即修改内容

注意事项

本质基本同新增，主要考虑哪些内容可以修改、哪些内容不可以修改；其次就是修改后内容一定记得做操作日志记录，方便后续追溯

数据库（SQL）语句

数据库层面对应语句就是update，代表更新数据。例如：要从数据库表名为“t_product”表中更新product_id=001的产品名称，则SQL语句为：

update t_product set product_name = “这是更新后产品名称” where product_id = 001 ;

API体现

1、请求方法：POST（HTTP通信规则中标准为PUT方法为更新数据）

2、定义接口路径，例如api/updateProduct

3、请求格式：基本同增

查：即查询、查找、搜索

定义

一般指通过某些内容查询符合条件的信息

注意事项

1、查询方式

1.1）输入框的查询类型：前缀、模糊、精确、批量搜索

1.2）非输入框的查询方式：单选、复选、单/复选兼容等

2、技术注意事项

针对输入框类型的内容，需要对SQL语句中的通配符（例如%、‘、“”等）做参数化查询处理，防止产生SQL注入风险

数据库（SQL）语句

1、数据库层面对应语句就是selete，代表查询数据。例如：要从数据库表名为“t_product”表中查找product_id=001的数据，则SQL语句为：

selete * from t_product where product_id = 001;

其中*代表结果返回数据库表中所有列，如果仅想返回产品名称，则将*替换为product_name即可。where后面的就是查询条件

API体现

1、请求方法：GET

2、定义接口路径，例如api/selectProduct

3、请求格式：一般也采用form data，例如查询字段为产品名称，查询内容为“这是更新后产品名称”，查询类型采用精确查询，请求字段为：

searchFields：productName

searchContent：这是更新后产品名称

searchType：精确查询

显：即显示、回显

定义

一般指将数据回显到页面上，供用户查阅。前端术语一般叫渲染

注意事项

1、如果是表单类，其一注意数据来源，其二注意是否需要分组，其三注意排序（降序、升序）

2、其次注意权限，什么人可以看到什么数据，保护数据隐私

3、其三注意数据回显方式，例如是否需要分页、如果不需要分页是一次性加载所有数据还是虚拟滚动加载或者某些字段加载过长时可以采用分步加载（即先加载主要数据，加载长的单独请求，这样不影响主要操作也减少用户等待）等

数据库（SQL）语句

本质对应的就是查询语句，只是拓展一些排序的概念，例如排序用order by函数，其中降序=desc，升序=asc。例如从t_product表中查询product_id大于1的，按照产品ID降序排，语句为：

select * from t_product where product_id>1 order by product_id desc;

算：即计算、算法

定义

一般指各种计算操作，例如求和、计数等

注意事项

一般算法涉及规则，需要明确规则的计算方式

数据库（SQL）语句

一般对应分组语句，即group by函数。例如从product表中查询平台=shopee的产品总数，且按照不同店铺聚合，语句为：

select shop,count(*) c_shop_count from t_product where platform=”shopee” group by shop;

其中c_shop_count为计数后的字段别名，用于承载计数后的结果。例如：t_product中有以下信息

执行上述计数语句后，则结果为：

其他一些算法函数，例如count计数、sum求和、avg求平均数、max求最大、min求最小，具体语法可自行某度

传：上传、导入等

定义

在设计中主要体现在上传信息的地方，例如上传图片、上传文件、上传视频等

注意事项

1、站在产品角度需要定义规则，保证传入数据的合法性。例如文件格式是否合法、文件大小、文件中行数是否有限制、文件模板是否被篡改、文件内容是否为空、导入数据格式校验等等

2、站在技术角度，以导入excel为例，处理流程就是：

2.1）读取excel文件：获取excel文件流 > 判断excel格式

2.2）解析excel文件：获取excel中sheet页数量 > 遍历所有sheet页中的总行数 > 解析sheet表中的行和列获取相应值

2.3）数据处理&存储：数据处理-格式化数据/数据清洗（例如某些字段要过滤空格）/数据校验等 > 数据存储-写入数据库

异常：异常场景、极端场景等

定义

异常指的时不再正常流程范围内，但是为了防止用户犯错，又需要增加的一些拦截措施

注意事项

1、系统内部交互时：考虑并发场景、考虑多人操作一条数据的情况、考虑数据状态合法性、考虑操作过程网络中断等

2、与第三方系统交互时：考虑接口QPS、考虑数据传输是否会出现重复创建情况、考虑授权异常情况、考虑接口请求时长断开请求后的补偿机制等

文章到此处就结束了，总体来说描述的还是产品经理的基本功，相信大家只要把自己的基础能力打扎实，肯定受益匪浅，因为基础能力不管做哪个行业都是可以平移的。其次就是方案靠谱，自己的专业性更能体现出来，也会让业务伙伴更信服。

大概啰嗦到这里了，也算一个入行N年的老朋友与其他朋友的交流，其次也希望作为新入行朋友的一个启发，如果有不正确或有歧义的地方，欢迎大佬评论区交流补充。

下期再见，bye～