“体育运动有规则，而对格斗来说，是没有规则的。所以为了迎接格斗，你应该训练身体的所有部位。”
——李小龙
前言
我参加工作是2006年，去的第一家公司是四维图新。那时在技术部从事软件开发工作，功能需求是由技术部的需求组提供的。业务部门要做什么东西，会先给需求组提需求，然后需求组将业务需求整理好，以需求单的形式提供给各个系统开发组。那时候，大家开会说“产品”，指的是公司出版的地图数据，而不是技术部门开发的各个系统、软件工具。学习的内容也是CMMI（软件能力成熟度模型）、RUP（统一软件开发过程）、MSF（微软解决方案框架结构）、UML。
2011年我加入艺龙旅行网，那时艺龙有这么两个部门，一个是网站产品组，一个是业务流程改进组。网站产品负责给面向消费者的预订网站提需求，而业务流程改进组负责给内部呼叫中心使用的系统、面向酒店的业务系统提需求。这两个组后来合并成一个产品团队。我在艺龙负责Ebooking产品的开发和运维工作，和产品经理打了3年的交道，期间自己学习了产品经理的相关知识并且担任一段时间的产品经理。
在艺龙期间以及后来的工作中，我看到一些团队的产品经理很优秀，开发人员技术也很强，但是有时候一个小的需求变更导致技术上的大调整，整个产品开发过程“鸡飞狗跳”，反倒有时候不如以前和一些经验丰富的需求分析师合作时候，产品开发过程更顺畅。
“产品设计”和“需求分析”比较
在传统软件开发企业和互联网企业都工作过的软件工程师，会发现“传统”需求分析师、“互联网”产品经理这两种角色工作内容有着一些明显的区别。
我们通过下面一个测试来了解一下大家所认为的这两个角色的工作内容。下面给出一些概念，如果你认为更接近产品设计，就在产品设计列打“x”，反之在需求分析列下打“x”。
| 名词 | 产品设计 | 需求分析 |
|---|---|---|
| 商业模式 | ||
| 用户体验 | ||
| 用户心智 | ||
| 用户习惯 | ||
| 用户愿景 | ||
| 用户需求驱动 | ||
| 业务需求驱动 | ||
| 渉众 | ||
| 用户角色 | ||
| 业务执行者 | ||
| 业务工人 | ||
| 以用户价值为中心 | ||
| 以业务需求为中心 | ||
| 甲方、乙方 | ||
| 数据分析 | ||
| 信息建模 | ||
| 信息架构 | ||
| 面向对象方法 | ||
| UML流程图、状态图、时序图、类图 | ||
| E-R关系图 | ||
| 需求文档 | ||
| 产品原型 | ||
| Rational | ||
| Axure RP | ||
| Sketch | ||
| UI、UE | ||
| 视觉设计 | ||
| 交互设计 | ||
| 业务用例 | ||
| 推广策略 |
以上概念基本可以分为“关注点”、“考虑问题的模式和方法”、“工作内容”、“常用工具”、“工作交付物”这么几类。相信大部分人选择的接近下面这个答案：
| 名词 | 产品设计 | 需求分析 |
|---|---|---|
| 商业模式 | x | |
| 用户体验 | x | |
| 用户心智 | x | |
| 用户习惯 | x | |
| 用户愿景 | x | |
| 用户需求驱动 | x | |
| 业务需求驱动 | x | |
| 渉众 | x | |
| 用户角色 | x | |
| 业务执行者 | x | |
| 业务工人 | x | |
| 以用户价值为中心 | x | |
| 以业务需求为中心 | x | |
| 甲方、乙方 | x | |
| 数据分析 | x | x |
| 信息建模 | x | |
| 信息架构 | x | |
| 面向对象方法 | x | |
| UML流程图、状态图、时序图、类图 | x | |
| E-R关系图 | x | |
| 需求文档 | x | |
| 产品原型 | x | |
| Rational | x | |
| Axure RP | x | |
| Sketch | x | |
| UI、UE | x | |
| 视觉设计 | x | |
| 交互设计 | x | |
| 业务用例 | x | |
| 推广策略 | x |
不知道大家做完这个测试后，是不是觉得做产品设计比做需求分析牛逼多了。很多产品经理的书籍中都会将“产品设计”描述的高大上：
- 产品设计是用户价值驱动，需求分析是业务需求驱动。
- 所谓设计，就是通过创造与交流来认识我们生活在其中的世界。好的认识和发现，会让我们感到喜悦和骄傲。
- 互联网产品设计绝不是编写产品交互说明书，也不是创造优美的界面，本质是创造一连串的体验，使用户能感知到产品的文化、价值和内涵，从而引发集群效应、创造社会价值。
以上的话说的都对，绝对正确。在乔老爷子的引领下，如今很多公司重视产品设计，这是好事。但是于此同时产生另外一种做法：不重视需求分析，甚至直接忽略。老板、产品经理这么做可以理解，工程师如果也这么附和，就是做事不过大脑。
需求分析是否有继续存在的价值
产品设计要取代需求分析，只可能是下面两种情况：
- 产品设计涵盖了需求分析的所有工作内容
- 属于需求分析但是不属于产品设计的工作内容已不再重要，可以不用去做
第一种情况，需求分析中的业务建模、画E-R关系图、UML流程图、时序图、状态图，在大多数公司中，是由需求分析师或者工程师来做，不属于产品设计的工作范畴。产品设计显然不涵盖需求分析的所有工作内容。
第二种情况，面对复杂业务场景，通过业务建模、画E-R关系图、UML流程图、时序图、状态图等手段做需求分析，是前辈软件工程师总结出来宝贵方法和经验。产品经理一般会将整理后的产品需求通过各种方式（口述、文档、UI/UE设计等）传递给工程团队，但是这些信息一般都是站在业务边界或系统边界描述的产品功能需求，和工程实现存在信息断层。产品需求如何映射到代码实现，需要一个系统化的需求分析、设计过程，产品设计并不解决过去几十年软件开发行业发明各种软件需求分析方法所解决的问题。任何脑袋没有烧掉的公司都不会说软件需求分析工作不重要、不需要做。
需求分析应继续得到坚持和重视
如果只关注产品设计，更多的时候，你会认为设计出来的界面很美观，交互也很舒服，该说的需求都告诉工程团队了，但是工程开发阶段，出现各种问题：概念不明确、架构无法设计、逻辑混乱、后期变更困难。
如果只关注需求分析，更多的时候，你会发现不知道如何提产品需求，产品开发出来了，认为做很牛逼，但是客户觉得不好用，产品不好卖。
所有公司都希望做出成功的产品。但是未经仔细思考，就忽略软件需求分析方法，不是一个经得起推敲的做法。只有产品设计、需求分析都做好了，产品才能成功。