万字长文：重构软件工程迷思，搞懂需求与产品思维

在上篇文章《一文搞懂架构顶层设计之业务建模》中，我们已经深入拆解了软件工程中的建模难题，这篇文章，我们将回到最开始的地方，拆解程序员每天打交道的需求和产品思维都是什么。

从软件工程与技术管理领域的“圣经”《人月神话》出版到现在已经50年，在这期间出现了各种各样的方法论，但到今天，大部分软件开发仍然处于“原始草莽”阶段。本序列试图通过个人多年/多家公司的架构岗位实践与思考，厘清各种方法论脉络，“重构”软件工程的理论体系（需求分析、建模、架构），尽最大努力建立“共识”。

关注腾讯云开发者，一手技术干货提前解锁👇

10/30晚7:30鹅厂面对面直播继续！

从软件工程与技术管理领域的“圣经”《人月神话》出版到现在已经50年，在这期间出现了各种各样的方法论（如下），但到今天，大部分软件开发仍然处于“原始草莽”阶段，个中原因已有连篇累牍的文献论述，不再进一步阐述。

本序列试图通过个人多年/多家公司的架构岗位实践与思考，厘清各种方法论脉络，“重构”软件工程的理论体系（需求分析、建模、架构），尽最大努力建立“共识”。

01

软件工程的“共识”难以建立，没有标准化的表达形式

所有方法论都是用自然语言表达，没有数学/物理公式的形式化语言，自然语言天然的2义性、歧义性，叠加每个人的认知差异，导致很多时候 “鸡同鸭讲”，“自说自话”。

看一下软件工程各个阶段的产出物的形式的多样化：

• 需求分析 tapd、在线文档、Excel、脑图、UI原型、业务流程图、“头脑中的隐性知识” 需求的表达形式不能统一，又怎么能指望产品/开发/测试/运营，对同1个需求的理解不出现大的gap? 有没有形式化的需求表达形式呢？有，比如《软件方法》所说的“系统用例规约”，方法论很多年了，有实践的团队屈指可数。
• 技术方案编写 业务架构图、系统架构图、时序图、类图、状态机、ER图、接口文档 … 业务建模、领域建模、数据建模、微服务拆分 … 名词看起来都是这些，不同团队对这些词的认知却差异巨大，产出物的形式自然五花八门。
• 开发及后续阶段 相对来说，代码应该是软件工程各个阶段中最标准化的一个阶段了。同样的开发语言、遵循同样的编码规范，读同1份代码，大家不会出现太大信息gap（没读懂除外）。

02

软件工程3大待厘清的领域

从需求到最终代码上线，也即完成现实世界->计算机世界的一次映射，在这次映射中，有3大复杂领域，之后就是写代码、测试、发布上线。

• 需求与产品方案；
• 建模；
• 架构设计。

因为这3大领域复杂，所以出现了各式各样的方法论，有的覆盖其中之一，有的覆盖其二，有的覆盖其三，但没有一个可以“包打天下”。

个人认为，要综合这3个领域形成一个体系，需要具备3个不同的思维模式：

所以，这里需要一个技术人员具备3个脑袋：

第1个脑袋：用户的脑袋（用户思维）

第2个脑袋：建模的脑袋（模型思维）

第3个脑袋：技术的脑袋（架构思维）

03

第1个脑袋 – 何谓“需求”？

先说我个人的一个观察：

市面上所有专门讲“需求分析”/“产品经理”的书、文章、博客等，全部都知识体系不完整、碎片化，为什么会这样？？？

我想这需要对“需求“这个东西的本质，也即对“产品经理“这个岗位有一个深刻认知，在我看来：

需求 = 认知

理解需求 = 理解现实世界

经济学对“需求”有一个严格定义：一定时间周期内，一定价格下，消费者愿意且能购买的商品数量。

但这个“需求”不是我们通常做产品所说的“需求”：

1. 这里说的其实是“供给”，不是“用户需求”。
2. 经济学的“需求”带价格，而互联网从做“免费”起家。

既然理解需求 = 理解现实世界，现实世界有什么？

现实世界 = 客观世界（技术） + 人 + 政治 + 经济 + 社会 + 文化 + …

人类所发明的每一个学科都只是现实世界的一个“切面”，并不完整反映现实。

需求 = f（技术、人、政治、经济、社会、文化…）

任何一个因素的变化，都可能导致“需求”的变化，进而产生新的商业模式、产业… 所以才有那句话：“产品经理是CEO的学前班“

《腾讯产品18讲》也反映了产品经理所需知识体系的综合性、多学科交叉性。

3.1 产品不是“需求”，产品是一种“供给”

“产品需求”这个词很容易误导，没有所谓的产品的需求，而是“用户的需求”，产品是针对用户需求提出的一个解决方案，产品是”供给“，不是”需求“。

那为什么我们经常说“产品需求”这个词呢，因为下面这个图：

对开发来说，那叫“需求”；

对产品经理来说，那其实是“解决方案”。

混淆“需求”和“产品方案”，会让我们失焦，找不到真正要解决的问题。

3.2 需求是一个大词，需要不断拆解

对需求的拆解过程，就是给需求“不断加定语“的过程：

• 吃
• 吃粤菜
• 吃便宜的粤菜
• 吃便宜的传统粤菜
• 吃家门口、便宜、传统、粤菜
• 节假日吃家门口、便宜、传统、粤菜
• 节假日、一家5口、吃家门口、便宜、传统、粤菜
• ...

所有定语，概括起来包含2个核心东西：

• 人
• 场景（什么场合）- 环境（时空）

需求 = 人 + 场景

进一步，“场景”这个词，拆解成“场”和“景”：

• 场：时/空，发生行为的背景，场合。
• 景：情景，人在这个场合下，产生情绪，产生动机。

在某个特定的场景下，人的某种动机才尤为强烈。

但这里，有一个两难困境：

需求拆解的越细，场景越明确，用户画像越明确，需求把握的越准；

但这样，匹配的用户就越少，商业价值越小。

为了扩大用户群体，很多产品开始增加功能，但这样会造成功能臃肿，用户体验下降，用户流失。

所以需要在“向下拆解“和“向上抽象”之间找平衡点，以“吃”这个需求为例：

3.3 需求的“众口难调”- 寻找最大公约数求是一个大词，需要不断拆解

不存在一个产品，其所有功能对其所有用户都是需要的，对1个用户有用的功能，对另外一个用户可能根本没价值。

怎么找最大公约数呢？有一个方法论叫《STP》

• Segment：对人群（目标市场）做细分。
• Targeting：在这么多细分市场中，挑哪一个搞？
• Positioning：确定了某个细分市场，接下来，为你的产品找一个“定位” ，即提供的用户价值。

这里举几个例子：

1. 宝洁洗发水； 上百个品牌（海飞丝、飘柔...），针对不同细分市场，提供不同价值点；
2. 携程酒店 vs. 美团酒店； 携程：商旅人士。 美团：本地人住本地酒店。
3. 小米手机； 从发烧友做切入点，也符合《创新扩散理论》
4. 迈克尔.波特的3大竞争战略； 成本领先、差异化、聚焦。 其中的聚焦战略，也是STP的意思。

3.4 需求的“永恒性”：消失的不是“需求”，是“产品”

在人类社会发展进程中，很多东西逐步消失了，举几个例子：

1. 网吧 用户没有上网的需求了？
2. 宝洁（海飞丝、飘柔） 用户没有洗头的需求了？
3. 柯达 用户没有照相的需求了？
4. 美特斯邦威、真维斯 用户没有穿衣的需求了？

3.5 需求的“永恒性”：成功的产品，通常都不是第1次做对应需求的

例子：

1. “搜狗输入法”不是第1个做打字的 五笔打字 -> 智能ABC -> 搜狗输入法
2. Chrome不是第1个做浏览器的 IE浏览器 -> Chrome
3. 小米手机不是在中国第1个做智能机的，华为更不是 各种山寨智能机 -> 小米 -> 华为
4. 杀毒软件 各种杀毒软件 -> 360

所以大部分商业上成功的公司，往往有这样的特点：

• 挑大众市场，成熟市场，需求早已被验证过，没有“伪需求”问题。
• 不“发现”新需求，“发明”的是新解决方案。
• 新解决方案，即新的产品设计/极致用户体验。

重要的不是“需求”，是提供“新产品”，“新价值”，“老树发新芽”。

3.6 需求的“永恒性”：人类的大部分需求永远无法满足

不管人类的世界如何进步，科技如何先进，怎是有各种各样的社会问题，每一类社会问题，对应了一类无法满足的需求：

• 房子
• 医疗
• 教育
• 大龄剩男/剩女
• 贫富差距
• 健康
• 环保
• 长寿/长生不老
• ...

3.7 需求的“永恒性” – 人性在几千年里前进了几厘米

马斯洛的需求层次理论。

• 懒（追求极致的“便利”，外卖、短文字、短视频、嘴巴说替代打字、...“奶头乐”）
• 虚荣心（时尚、爱美、攀比，“女人的钱最好赚”）
• 性（好美/好色）
• 七宗罪
• 佛家 – 贪嗔痴

3.8 需求的“变化性”：《PEST》模型

宏观需求是不变的，永恒的，一直变化的是“微观需求”。 微观需求为什么会变化，这里提供2个视角来看待，第1个是《PEST》模型：

• Political
• Economic
• Sociocultural
• Technological

也即人类的变化，主要由这四大方面的变化所驱动。

3.9 需求的“变化性”：微观的供需不平衡

供需，只有2种状态，“供”和“需“。

但同1个需求，在不同细分场景下，不同的时空中，可能供 > 需，也可能供 < 需。

1. 供需受“空间”影响的例子：
   1. 房地产 整体：供 > 求 某个城市/某个地段：供 < 求
   2. 便利店 深圳宝安区：供 > 求 你家附近：供 < 求
   3. 大白菜 你家农村：供 > 求 东北某个农村，供 < 求
   4. 共享单车 郊区：供 > 求 市中心地铁口：供 < 求
   5. 清朝的晋商 – 去内蒙古卖茶叶 武夷山：供 > 求 草原：供 < 求
2. 供需受“时间”影响的例子：
   1. 地铁 平常：供 > 求 上下班高峰期：供 < 求
   2. 机房机器 平常：供 > 求 用户高峰期：供 < 求
   3. 滴滴打车 白天：供 > 求 晚上10点，互联网公司门口：供 < 求；
   4. 景区/酒店/机票 平常：供 > 求 节假日：供 < 求
3. 互联网的出现，打破了原有的“供需平衡”
   1. 淘宝 没有淘宝的时候，你家门口的五金店：供 < 求; 有了，供 > 求，家门口的五金店倒闭了。
   2. 外卖 没有外卖App的时候，你家门口的星巴克：供 < 求； 有了，你可以从附近3公里的所有星巴克下单，供 > 求；
   3. 你家门口的一个很好吃的小店 没有外卖App，供 > 求，用户不多，非常好吃； 有了外卖App，成了网红店，供 < 求，用户大量涌入，质量下降。

04

产品定位 – 何谓“价值”？

价值有2种：

• 用户价值。
• 商业价值（商业化）。

前者是后者能存在的前提，这里只讨论前者。

既然宏观需求不变，变化的是微观。那“用户价值”就是找到微观层面的需求变化，抓住“最细微幽深”的变化点，也即抓到机会。 “用户价值”之所以很难定义，是因为有些价值偏客观，有些价值偏主观。

例子：

• LV包包，你认为有价值，别人认为没价值；
• 炫富，对你来说不是需求，对某些人就是需求；
• 设计感、美感，对某些人来说有价值，对另外一些人没价值；
• 某个产品的用户体验，你觉得好，别人没感觉；
• ...

所以有本书叫《定位》，讲营销的，认为 认知 > 事实，即建立产品在用户心中的“心智模型”。

事实上”有没有价值“不重要，用户认为”有价值“就行。

价值的主观性，再往下讨论，会扯到人性、哲学：

• 懒（追求极致的“便利”，外卖、短文字、短视频、嘴巴说替代打字、...“奶头乐”）。
• 虚荣心（时尚、爱美、攀比，“女人的钱最好赚”）。
• 性（好美、好色）。
• 七宗罪。
• 佛家 – 贪嗔痴。
• 七情六欲 – 哪七情哪六欲。
• 《乌合之众》，群体的智商低于个体智商。
• …

事情一旦扯到人性，很容易变成“玄学”。人性，人人都懂，也人人都不懂。

4.1 用户价值 – 理性部分与感性部分

为了能更进一步讨论用户价值，这里我把价值分为理性部分和感性部分：

• 理性部分

便宜、方便、耐用、物流快、售后好...

比如京东的Logo，“多快好省”

• 感性部分

酷、爽、美、时尚、有趣、好玩、特别、..

越偏创意类产品，感性部分越多（比如电影/游戏）；

越偏实用类产品，理性部分越多。

个人认为：“价值的不好把握，是商业世界最难搞的事情之一”。在这方面，即使世界上最伟大/最成功的公司，照样犯错误。

关于价值的“感性部分”，业界也有一个总结，“3点论”：

• 痛点：来自“恐惧”
  • 对生存的恐惧 – 便宜，实用，耐用，种类丰富
  • 对威胁/暴露的恐惧 – 安全软件
  • 社交恐惧症 – 表情包、点赞、朋友圈
• 爽点：来自“即时满足感”，极度没耐心（奶头乐）
  • 外卖
  • 短视频
  • 微博
• 痒点：来自“人想活在自我的虚拟世界，不愿意面对现实”
  • 游戏、网络小说

4.2 用户价值的“比较性”

很多需求是永恒的，不变的，变化的是人类发明的一个个产品（即需求的解决方案），而衡量产品的“用户价值”的另外一个办法是比较

用户价值 = 新价值（你的） – 旧价值（别人的） – 切换成本

这里的“价值”，包含了上面说的理性价值 + 感性价值

例子：

• 五笔打字 -> 智能ABC -> 搜狗输入法
• IE浏览器 -> Chrome
• 打电话点外卖 -> 外卖APP
• 现金找零 -> 手机支付

4.3 何谓“伪需求”？

经过上面的讨论，会发现，“伪需求”有这样几类：

1. 需求是“真“的，但有这种需求的用户量太少，做这种需求ROI太低。
2. 需求是“真”的，“伪”的是产品功能，产品功能没能真正解决用户问题，提供用户价值。
3. 需求是“假“的，YY出来的用户需求。

05

何谓 “用户体验” ？

定义：用户用最小成本/最小代价使用产品功能满足自身需求。

从这个定义上来看，用户体验和用户价值的“比较性”是一脉相承的。

互联网产品，常说的用户体验主要指网站/APP的使用体验：

• 网页的加载速度
• 上传文件速度
• 页面渲染速度（Chrome vs. IE）
• App占用内存大小
• 聊天软件传超大文件
• 页面跳转次数
• 按钮大小
• 按钮位置
• UI界面的简洁、美感（字体、字号、颜色）
• …

那些看起来琐碎、不起眼、没技术含量的“交互细节/界面细节”，却构成了“用户体验”的核心，需要“偏执狂”/“细节控”的产品经理去不断打磨。

但这容易导致对“用户体验”的狭义理解：

1. 用户体验不仅仅局限于 UI设计/UX设计 例子： （1）电商 物流速度、退货便利度 >> APP的交互设计/UI设计 （2）打车软件 打车接单速度>> APP的交互设计/UI设计
2. 互联网行业追求极致的用户体验，把这个当核心方法论。其它行业一定可以效仿吗？ 并不能，因为互联网产品天生的边际成本趋近0，而在传统领域，更适用的是《4P理论》

所以这里要扩展一下“用户体验”的定义：对于实体商品，“价格”就是用户体验最核心要素

06

从需求到产品的推导链条

最后做一个总结，从需求到产品的推导逻辑：

07

何谓“战略”？ - “战略”能推导出“需求”吗？

MBA/商学院，关于战略的研究连篇累牍，有各式各样的战略学派：

定位学派： 关注“外部”

• 市场分析：蛋糕多大/蛋糕多少人分
• 产业链分析
• 选正确的赛道
• …

能力学派：关注“内部”

• 核心竞争力理论
• 精益管理

创新学派：

• 商业模式创新
• 企业家精神
• …

战略通常会关注下面几类问题：

• 市场分析（同类型业务）
  • 市场规模（蛋糕多大？） - 规模效应
  • 市场划分（蛋糕多少人分？） - 马太效应
  • 增量 vs. 存量市场？
• 产业链分析（生态链）
  • 《微笑曲线理论》
  • 《生态理论》
• 产品/市场营销
  • 《STP理论》，
  • 《4P理论》，
  • 《创新扩散理论》
• 企业- 核心竞争力
• 商业模式

按上面所说，战略这么多学派，定义都不一样，作为”战略的业余人员“，怎么通俗理解这个词？

战略 = 一种科学假设 = 1种选择 = 取舍

战略 ！= 目标，战略！= 愿景

战略是一种“假设”，即为了达到目标，从众多路径中选择“其中1条路径”，即战略 = 一种选择，也即舍弃了其它路径。

更进一步，战略不是“一个选择”，是“一组选择”，是“1套组合拳”，更准确的说，叫“一组策略”。

• 市场的战略
• 产业链战略
• 营销的战略
• 产品的战略
• 研发的战略
• 运营的战略

在互联网/科技这种需要不断创新领域，容易犯错的是下面这条路：

从战略推导需求，即使大公司，在这个问题上仍然会犯错。犯错的主要原因是上面说的“需求”的主观性，当一群人在办公室讨论战略，推导需求，离一线太远，往往也就离用户太远。

08

需求分析：ToC与ToB方法论的差异

ToC与ToB都做产品，上面讲的是共性，接下来讲差异。 在对应岗位上，有明显体现：

下面表格列举了ToC与ToB在做产品上的一些关键差异点：

在这么多差异点上，最根本的有2个差异：

（1） 体验 vs. 价值

ToB，更追求“商业价值”，无论是对产品的提供者，还是对产品的购买者，都是“做生意的人”，都追求商业价值；

ToC，追求用户价值/用户体验，而前面所说，用户价值中的“感性部分”，很难挖掘与把握。

（2）人性 vs. 行业知识

ToC，要求深刻理解“人性”；

ToB，要求深刻理解“行业知识“

每一个业务领域，都发展几十甚至上百年，沉淀了相当多的行业规律、行业标准、思维模型，做ToB需要尊重这些行业规律、底层逻辑，以下举几个例子：

• 零售：人货场模型
• 财务：3张表
• 金融：资金流模型
• 反洗钱：FATF国际标准

后续要讲的“建模”，也是基于对这个常识的尊重； 没有对领域知识的尊重，不会有好的建模。

基于以上差异，下面总结了ToC和ToB 2种方法论在思维链条上的一些差异：

09

软件工程的2个流派

需求的变化性，商业的复杂性，ToB与ToC的差异性等等， 延续到软件工程，自然产生不同的软件工程流派。 流派很多，应该说是一个频谱，频谱的两端是2个极端。

方法论1: 古典学派

把软件工程的每个环节都往标准化上做，尽可能有形式化规约，让每个环节都“有章法可依”

方法论2：不拘泥形式，怎么实用怎么来

遇到问题解问题，靠“聪明才智”弥补经验缺陷，“乱拳打死老师傅”

方法论1:

1. 业务建模的输出产物：业务用例、业务流程图（业务时序图）。
2. 根据业务流程图，推导出系统用例、系统用例规约。
3. 根据系统用例规约，推导分析系统时序图/类图/状态图。

方法论2: 强调“小步快跑，快速迭代”

• 没有标准化的业务流程图，每个产品经理画图、写文档风格都有差异。
• 没有标准化的系统用例图、系统用例规约。
• 没有标准化的系统设计方案，UML图，甚至没有技术方案文档，直接写代码..
• …

但互联网的产品方法论，有其另外一些非常核心的价值观/原则：

• 非常重视用户体验，UI界面操作流畅度；
• 非常重视客服（客诉处理）；
• 非常重视产品上线后的持续运营；
• 非常重视“数据驱动”，从各种监控数据中去发现产品缺陷、系统缺陷；
• …

实际工作中，大部分团队是趋于2者之间，不是完全没有方法论，也不是严格遵循方法论。这也导致不同团队、不同研发人员、产品人员之间，在跨团队沟通协作时，首先面临思维方式对不齐、“沟通语言”对不齐问题。

10

需求分析的产出物

经过上面分析，可以看到，从粗到细，从宏观到微观，产出物包括：

• BRD(Business Requirement Document) 战略（市场分析，竞品分析，用户价值，商业模式...）
• MRD(Market Requirement Document) 目标用户，前期推广计划，资源投入。
• PRD(Product Requirement Document) 产品功能、UI、UX。
• FSD(Functional Specifications Document) 接近技术实现。

11

技术人员在需求阶段的角色定位

在需求阶段，技术人员有2种不同的参与需求的模式

模式1: 产品经理定义需求 + 产品方案，技术挑战、提建议

大部分产品都是这个协作模式，技术人员对哪些进行挑战呢？

（1） 挑战产品方案

无论产品方案，还是技术方案，都是“方案”，不是需求。 基于技术可行性与成本，换一个产品方案，可能同样能满足用户需求。

（2） 需求与产品方案都合理，但产品细节有逻辑不自洽

比如业务规则自相矛盾、有漏洞、异常处理流程考虑不全等。

模式2: 技术产品经理

对于偏技术的中台/平台型产品，比如PaaS平台、云平台、基础组件、风控策略平台、机器学习平台、低代码平台等，因为技术专业性强、用户是公司内程序员、算法/模型人员，更适合由高阶技术人员兼任产品经理。

在这个模式下，技术人员是否具备产品思维，往往是这个平台能否做成的关键。

至此，讨论完技术人员应该具备的第1个脑袋，下个序列讨论技术人员需要具备的第2个脑袋：“建模思维”。