从今年下半年，我开始逐步接手公司整条产品线。也就是电脑端和移动端的功能设计，都是由我来完成。

因此，需要我逐步对公司的业务有更深的认识，而不单单仅局限于单点功能。

还是这张图，让我们先来看看产品定义里的需求分析中，业务逻辑这部分。

一、什么是业务逻辑？

首先，先让我们来简单聊聊什么是业务。

我的理解是：行业下，企业各类角色协同办公，完成公司向上运作，并获得盈利。

这当中包含两个关键因素：行业模式和运作流程。

（1）行业模式：宏观层面的大格局，界定了企业运作的范围；

（2）运作流程：微观层面的小视野，每个企业都有自己的玩法；

而业务逻辑，就是要将行业模式和运作流程串起来。

本质上，是避免产品经理从产品向上看业务，而是要从业务向下理解产品。

前者是站在井底看天，后者是站在井外看世界。

二、怎么理解产品的业务逻辑？

01、业务逻辑，不是业务流程

一开始，我会将这两个概念混淆。

不仅是因为这俩长得很像，还有一点就是我一直在低头做事。

关注产品细节，纠结交互逻辑。

这当然没错，也是初级产品经理的主要工作。

不过如果我们想往上走，也一定要抬头看天，一点点的拔高自己的视野。

看到这，不知道你是否理解了两者的区别？

（1）业务逻辑：颗粒度粗，关注的是行业格局和企业运作。

以我现在公司做的智能视频监控为例，下图是大致的业务逻辑。

但从颗粒度上来看，还是不够细致，未来我会补充完整的产品全景图。

（2）业务流程：常用于功能设计，颗粒度很细，具体到开发可落地的产品方案；

下面这个做的是任务停用功能的流程，也比较简单，用来举例说明。

02、理解业务逻辑的几个实践方法

过去在我只负责后台功能设计时，我是不会去了解这些的。

一是自己手头的工作做得不好，二是思想上懒惰，总想着这是别人负责的，和我没关系。

但当你能熟练掌握手头工作时，可以去寻找有价值的新内容。

要知道，如果只是局限在手头的工作，成长速度就太慢了。

只有你开始做了，后面才会有故事。

1、多用产品跑流程

看产品文档和使用产品是一套组合拳，结合起来才能叫实践。

一般公司都会有测试环境，注册几个测试账号，就可以开始了。

过程中，可以多做记录，记下自己的疑惑。

自己多想想，不懂的问问同事，一般 1 到 2 天就熟悉的差不多了。

2、多观察用户怎么用产品

尤其是 B 端产品，目的是为了解决客户工作中的问题。

因此只关注产品逻辑是不够的，要多了解用户线下到底是怎么使用的。

以我们的 App 为例，有条产品线是将用户的线下巡检线上化。

简单说，就是用户拿着手机，照着后台系统下发的任务，完成巡店检查。

之前有客户提出一个诉求，希望能解决违规图片准确性和时效性的问题。

最后，产品这边提出用照片携带水印的方式，与客户确认后觉得可行，就做了这样的配置。

但问题是，我当时做的是「拍照携带水印」。

在我的理解里，就是边拍照边做检查。

但上线后发现，不同用户有不同的习惯。

除了我上面提到的，还有一种是拍好了所有的照片，找个地方写文字，然后一张张上传图片。

这就导致了水印无效。

说白了，这就是不理解业务的办公室产品经理。

3、多听听产品的负面反馈

没有一款完美的产品，产品经理要多听听用户怎么吐槽。

哪里不好用？为什么不好用？造成了什么困难？

深入到这部分用户身边，多去了解和感受，摒弃自己的主观意识。

这段时间，我对此的感受也越来越深。

逻辑合理只是一方面，重点是用户觉得它合理。

写在最后

以上是我目前对业务的理解，也是我下一步要提升的格局。

当然，这需要长时间的实践与积累，并不是学几节网课，看几本书就能行的。

一步步跨越，一步步成长。

愿你我终将成为一名产品人，而非工具人。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

这是《薛兆丰的经济学课》第 3 部分，讲的是经济学角度下的需求。需求这个词，现在已经变成人人都用的高频词了。从产品角度来说，需求是指人内在需要，成本可控且能实现的解决方案。就好比，我想喝可乐（外在想要want），是因为我渴了（内在需要need），但手上的钱只够买水（能实现的需求demand）。那么，回到经济学的角度，需求又是在讲什么呢？

一、个人估值与边际

支撑需求的两个关键要素，是价格与需求量。

而他们两变化的高低，会跟个人的判断有很大相关性。

01、个人估值是完全主观的

商品的价格，会受需求的变化而变化。

就像最近高考前，保健品销量走高，价格也随之上涨。

但如果说需求决定了价格，那么购买与否是由谁决定的？

答案是个人。

有时候，买它不光是看它是否有效，还有心理作用。

就好比保健品这件事，我买了，孩子吃了，那就跟别人一样了，咱们家没落下。

这就是主观判断下的个人估值。

02、个人估值是基于行动的，不是单纯的愿望

还是上面保健品这个例子，如果我觉得它值得，我就一定会买。

无论过程中心里有多犹豫、多矛盾，看的只是最后的结果。

当然也会有人说，我是真的想要，但就是客观条件不允许，是真的没能力，这不也很常见吗？

但你要知道，人是有能动性的，会为了达成目采取各种行动。

就比如家里买不起保健品，那就多吃点核桃，这不也是一种替代方案吗？

所以，只要你觉得这件事值得，你会不顾一切的想办法去解决。

03、边际就是“新增”带来的“新增”

我们常说，做任何事都需要考虑成本。

如果这件事是连续性的，这个成本其实指的是边际成本。

比如我们花 1 块钱买个馒头，吃完后差不多饱了。

再花 1 块钱买馒头的成本，已经高出第一次的了。

要知道，虽然价格都是 1 块钱，但它达到的效果是在递减的。

此时，我们更可能的是花钱买水喝。

这是因为相比买馒头，买水获得的收益更高。

二、需求第一定律

01、永远向下的需求曲线

图片来自于得到课程

当价格发生变化，需求量也发生变化，而整条曲线构成了需求曲线。

注意，单纯的价格变化无法影响需求，只会影响需求量。

肉的价格升高，那么它的需求曲线不会变化，只是需求量降低了。

反而蔬菜的需求曲线会发生向上平移，即虽然是相同的价格，但需求量反而增加了。

02、需求与供给，取决于市场价格

图片来自于得到课程

商品的价格不会无止境的上升，达到一定程度，需求者会变成供给者。

要知道，人都渴望抓住机会，获得更多的收益，这也符合市场规律。

买的人多了，价格就会上涨，此时自然有更多的人去卖。

但当卖的人多了，又会相互竞争压价，最后价格会相对平衡。

三、需求第二定律

01、随着时间的推移，需求对价格的弹性会增加

图片来自于得到课程

单看公式，比较难理解，我们只需要记住一点。

那就是，商品没有绝对的需要与不需要，只有个人估值的值得与不值得。

就比如过去口罩算是非必需品吧，但因为这次疫情，需求量的变化比例激增，政府控制价格变化，口罩也就成为了必需品。

再比如地铁算是交通必需品吧，但如果价格上调，会有人选择其他交通工具出行。

那如果一直上调，相信地铁也就成为了交通奢侈品了

总结来说：弹性＞1，商品为奢侈品；弹性＜1，商品为必需品。

02、垂直的需求曲线

既然有倾斜向下的需求曲线，那会不会有垂直的需求曲线呢？

图片来自于得到课程

如果要解释的话，那就是随着价格的升高，需求量保持不变。

简单来说，就是我们常说的刚需。

那么，现实中是否会有这种情况呢？

答案其实是没有的。

“人性的特点，就在于它能够寻找替代方案。”

结婚结不起，人选择独身。

买房买不起，人选择一辈子租房。

生病吃不起药，人选择死亡。

其实，上面的例子是比较极端的，实际中的人是会有更多对策。

大多数情况，既然高不成，人是会主动或被动地选择低就。

03、谁付出的多，取决于他们之间的相对弹性

就拿男女交往这件事来说，到底是谁离不开谁，或者说，谁在恋爱中更主动？

其实看得是谁更需要对象，或者说需要一段亲密关系这件事。

这就是我常说的，谁认真谁就输了。

那是因为认真对待的人，往往更需要这段关系，如果用经济学的理论来解释。

（1）弹性大 → 选择更多 → 非必需品；

（2）弹性小 → 选择更少 → 必需品；

这种个人估值判断，也决定了你在恋爱中的地位。

四、需求第三定律

这部分，是薛老师补充的另外一点。

简单说，就是“附加成本，使得精选产品相对价格下降”。

比如你出国去玩，能够带 1000 毫升的液体回国，你会选择什么？

苏打水？啤酒？红酒？肯定是个人估值最高的商品。

这就是附加成本自身，给商品带来的筛选作用。

写在最后

这个章节概念比较多，而且涉及到很多数学模型。

重点是，要能理解这些模型背后意义，并能够引发对现实事物的理解。

其实你会发现，人的大多数行为，其实都逃不开经济规律。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

在系列文章产品管理流程及规范（二）——产品需求的时候，对需求层级、需求来源、需求收集做了分析，但对需求的管理及迭代规划未作进一步说明，所以本篇文章对此进一步展开分析。

需求管理

需求池

需求收集之后进入进入正式的需求池进行管理，可以按照一定的时间比如每周一次从各方收集需求，并进行初步沟通之后，放进需求池。并根据需求本身的变动，调整需求池中的相关状态，标注相关的记录，批注。

ID——需求的唯一ID号，需求身份标识，增加一个需求ID增加1

端口——需求所涉及的端口，前端如——安卓、iOS、小程序，后台——平台、供应商、商家，这里是对需求做一个初步的划分，如果涉及到多端，一般记为综合或拆分成多条子需求对应到各端口。

模块——需求所涉及到的模块，例如会员管理、用户管理、商品管理等；

需求名称——简单描述需求是做什么的；

需求描述——更详细描述需求的相关信息，例如需求提出的背景、需求要达成什么目的、需求的详细说明等；

需求来源——记录需求的来源方，例如产品、市场、运营；

类型——”记录当前需求的类型，a、新功能；b、功能优化；c、bug修复”；

优先级——记录需求的优先级，a、一般用高中低；b、数字表达；c、需求的优先级是动态的，会随着战略、业务目标的变化而调整”；

提出时间——记录需求被提出的时间；

提出人——提出这个需求的人及联系方式，有助于在需求详细设计时追踪到原始需；

状态——”需求当前的状态，根据不同的阶段，可以大致分为；

a、记录——进入需求池（初始状态）；

b、论证——需求开始评估论证；

c、待设计——论证完成后有价值并决定近期开展后续工作；

d、设计中——正在进行详细设计；

e、设计完成——原型及UI已经设计完成；

f、研发中——已正式安排研发周期；

g、已上线——需求正式上线；

h、已关闭——针对需求因各种原因提前终止其生命周期；

预计版本——对需求计划上线的版本进行规划，产品部门规划的实现版本往往会超前正在研发版本；

实际完成版本——版本上线后，更新需求实现的实际版本号；

上线时间——记录版本实际上线的日期；

备注——各种情况的补充说明，例如需求关闭的原因，需求优先级变动原因，版本规划变动；

需求优先级

需求优先级的分析可以采用KANO模型、四象限法则、权重加权三种方式进行：

KANO模型

以分析用户需求对用户满意的影响为基础，选择了两个维度：a、需求实现度；b、用户满意度。用这两个维度将需求区分，将需求分为5种，分别是：兴奋型需求、期望型需求、无差异需求、基本型需求、反向需求，针对不同类型的需求采取不同的措施。

A、兴奋型需求——也称魅力型需求，随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。

B、期望型需求——也称为意愿型需求。是用户的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，企业提供的产品和服务水平超出用户期望越多，用户的满意状况越好。比如说，支付方式，相对来说，是越多越好，这样用户会有更多选择，当没有一种支付或是其中一种没有资金的时候还有别的可供选择，能覆盖更多的用户。

C、无差异需求——不论提供与否，对用户体验无影响，比如现在各平台都有的签到，打卡功能。

D、基本型需求——也称为必备型需求、理所当然需求，是用户对企业提供的产品或服务因素的基本要求，比如现在互联网基本都有的客服功能。

E、反向需求——又称逆向型需求，指引起强烈不满的导致低水平满意的需求，比如将产品流程设计的非常复杂，引起用户反感。

四象限法则

四象限法则将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类。选择的两个维度是：紧急和重要。

第一象限——这个象限包含的是一些紧急而重要的需求，这一类的需求具有时间的紧迫性和影响的重要性，无法回避也不能拖延，必须首先处理优先解决，比如支付功能出问题。

第二象限——需求不具有时间上的紧迫性，但它具有重大的影响，需要ｗｂｓ方法分解任务、提前进行规划，按照计划逐步执行，比如数据埋点统计分析

第三象限——需求大多是些琐碎的杂事，没有时间的紧迫性，没有任何的重要性，这种需求的提出本身就存在一定问题，没有考虑清楚，可能是头脑发热，也可能是看着别人有就想做，与本身产品没有任何关联性，对这类需求可以放任不管，比如后台目录的颜色美观性

第四象限——是那些紧急但不重要的需求，这些事情很紧急但并不重要，比如由于商品图片过大导致的加载慢（可以通过优化压缩上传图片解决）等，可以先采用替代方案执行

权重衡量

对需求赋予一定的指标，进行量化分析，如工作量大小、对用户价值大小，对公司价值大小、紧迫程度、与核心流程相关性，可以将各指标赋予一定的权重（所有指标项权重相加为1，各指标项确定各自的程度数值，工作量按天计算时间越大，赋值越低）进行加权，得出综合值大的，则优先级高。如下图，需求2的综合得分为6.8》需求2的综合得分5.6，先做需求2

迭代规划

固定任务

任务量固定，时间上可以进行调整，比如一个大的版本上线，新开的功能模块上线，即使采用MVP的方式，也会超出一般迭代的周期。这种方式一定是以保证业务、功能需求的完整性，系统性为主，不能完全按照时间来。否则的话，功能逻辑的完整性和链条就会缺失，上线之后会带来极坏的影响，如果功能不完整还不如不上线的好。

固定周期

当产品进入稳定期之后，业务也较为稳定顺畅，则按照固定周期进行迭代，比如两周时间上新一个版本，则以时间为准，固定时间端，按照优先级并考虑工作量合理安排需求。

紧急需求

在上一个版本发布之后，发现重大ｂｕｇ，需要紧急修复上线，这种肯定不能按照常规方式处理，直接将优先级提高，修复上线。

插入需求的处理

紧急需求与插入需求有些类似，均是常规计划之外的。但两者又有不同之处，紧急需求是不得不做的，不做将会带来严重影响的。但插入式需求是计划已经排定，但又有新的需求进来，比如业务部门，上级领导等。这个时候从几个方面进行处理：

Ａ、先不急着拒绝，先分析需求的优先级，如果需求确实优先级高，看需求规模，工作量大小，人力资源，是否能不动本次版本需求的基础上进行增加，如果可以则直接增加进去，如果不行，则将优先级低的需求进行删减。

Ｂ、需求优先级不高，则沟通安排到之后的迭代，并讲明原因

总结

本文主要对需求的层级、需求来源、需求收集方法、需求管理池、优先级的确定及需求迭代进行了分析。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！