优秀开发者的第一步：始于需求分析

近期，在培训 IPD 流程时我们提到：开发的第一步是需求分析。那么，为什么要做需求分析？以及如何做好需求分析？今天让我们一起聊一聊需求分析这个话题。

为什么要做需求分析

首先，当然是因为我们做软件本身就是为了满足用户的需求。那么，用户需求到底为何，我们需要先清楚定义。

其次，需求边界定义的需要。用户需求理清楚了，不代表产品理清楚了。用户需求的满足一定会有行业的分工，不同系统之间的分工，我们做什么，上下游合作伙伴做什么，需要厘清边界。

最后，架构设计的需要。架构需要切分子系统、子模块、子接口，需要我们梳理并对用户需求进行归纳与抽象。架构还需要避免过度设计，把简单的事情复杂化。

什么是过度设计？如何判断？ 理解定义：不会发生的事情你考虑了并且为它做足了准备，这就是过度设计。 如何判断：判断是不是过度设计是比较困难的，需要对需求的未来演化有很强的判断力。

从几个不同的维度来看，需求分析过程会涉及到以下这些内容：

• 我们要面向的核心用户是谁？

• 用户的核心需求是什么？最为核心的问题是哪几个？

• 已经有哪些玩家在里面？上下游有哪些类型的公司？在我们之前，用户是怎么解决他们自己的问题的？我们的替换方案又是怎样的？相对比有何优势？

• 我们的产品给用户创造的价值点是什么？用户最关注的核心指标是什么？

这几个问题也是我在平时面试过程中一定会问求职者的几个问题，用以评估求职者是否了解自己为了什么而开发，还是为了开发而开发，这点非常重要。

当然，这里并不是说，我们应该在需求分析的文档中完整地回答这些问题。需求分析文档的目的并不是回答这些问题，但是在我们梳理需求的过程中，我们无法回避对这些问题的思考。

可能有同学会认为，这些问题是产品经理这样的角色去回答的，而不是开发需要去回答的。

某种意义上来说这句话的确没错。回答这些问题的首要责任方是产品经理或 CEO 等角色，这些角色是有责任让团队中的每一个人理解产品。

但是，如果开发者只是被动地接受产品需求，以按图索骥的方式来做开发的架构设计和编码开发，这是不足以让自己成为一名优秀的开发者、优秀的架构师，原因会有两方面：

一方面，用户需求的深层理解是很难传递的。你看到的产品文档、产品原型，参加的产品原型评审会，这些是产品经理和用户沟通交流后的二次理解，是对需求的提炼和二次加工，很难原汁原味地传递用户的述求。

所以，开发者自己亲身近距离地接触用户，和用户沟通，去体会用户的述求是非常有必要的。 这方面在我们团队中的绝大部分人，当下做的还很不好，仍需努力提升。

同时，绝大部分人并不会那么仔仔细细地阅读别人写的产品文档、产品原型。当然这不完全是看文档的人单方面的原因，如果团队文档平均质量不高的话，也会影响到阅读者的心态。

另一方面，产品设计过程需要开发者的参与，而不是单向的信息传递。产品经理非常需要来自开发者的建设性意见。

所以，8 月份新优化的 IPD 流程中，已经在产品原型的内部评审阶段，主动邀请技术经理等其它角色提前参与进去，围绕产品设计提出技术维度的建设性意见。

为什么我自己会有这样的看法呢？这个涉及我对产品的理解：我理解的产品本身是运用新技术来满足用户需求过程的产物。但是，用户需求的变化相对是缓慢的，真正在不断改变的是需求的满足方式。而需求满足方式的变化，深层次来理解，其背后往往是由技术迭代所驱动。

参考混沌大学李善友教授的课程：第二曲线创新。这里指的新技术包含用户需求所处的环境改变，比如：Web 从 1.0 进入到 2.0，终端设备从 PC 端进入到手机端，SaaS、小程序、AI 等。

从这个角度来说，产品是一座桥，它一端连接了用户需求，一端连接了先进的技术。因此，产品经理是需要有一定技术高度的，他不一定要深刻了解技术的原理，但是一定要深刻理解新技术的边界。某项技术能够做什么，不能做到什么。优秀产品经理甚至比实现这项技术的开发者还要清楚。

认为产品经理不需要理解技术的，这可能是我们普遍存在的行业现象，但这很可能并不符合这个岗位的内在诉求。

产品经理和优秀的开发、架构师其实是一体两面。两者都需要关心用户需求，只不过产品经理更多从用户需求出发，而开发者更多从技术实现出发，两者是在产品这座桥的两端相向而行，最终必然殊途同归。

这其实也是我为什么认为开发者需要参与产品设计的原因。产品经理很可能会缺乏他应该有的技术广度，这时就需要开发者去补位。

我个人认为：作为一名优秀的开发者或架构师，在整个产品开发设计的过程中，至少应该花费 20% 的精力在需求分析上。需求分析它并不是纯技术的东西，本身和编码无关。它关乎的是用户需求的梳理、需求可能的演变方向。并且，需求分析的准确是做出良好开发架构设计的基础。

如何做好需求分析

首先，心态第一，心里得装着用户。除了需要 “在心里对需求反复推敲” 的严谨态度外，对用户反馈的尊重之心也至关重要。

其次，对问题刨根究底，找到根源需求。有很多用户反馈需求的时候，往往已经带着他自己给出的解决方案。这种需求反馈已经属于二次加工的需求，而非原始需求。这个时候我们要多问多推敲，把它还原到不带任何技术实现假设的根源需求。

最后，在理清楚需求后，要对需求进行归纳整理。一方面，将需求分别归类到不同的子类别中，另一方面，对需求的变化点和稳定点的基本判断。

在需求分析时，要区分需求的变化点和稳定点。稳定点往往是系统的核心能力，而变化点则需要对应地去考虑扩展性上的设计。

需要注意的是，在讨论需求的变化点和稳定点的时候，我们需要有明确参考的坐标系。往往在不同视角下，稳定点和变化点的判断是可能完全不同的。

比如我们要设计一个电商的黄金下单流程，那么，多样化的营销能力是一个变化点。但是如果我们今天是在设计一个抽奖的营销插件，问题域就完全变了，需求的变化点和稳定点也就完全发生了变化。

本质上来说，对变化点的梳理，是一次产品边界的确立过程。所谓的开放性设计，就是说我把这个功能交给了合作伙伴，但是我得考虑怎么和合作伙伴配合的问题。

开放性设计并不是一个纯粹的用户需求问题，它通常涉及技术方案的探讨。因此，产品边界的确立不是一个纯需求，也不是一个纯技术，而是两者合而为一的过程。

用思考的方式去记忆，而不是用记忆的方式去思考。