众所周知程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的东西，程序员真正需要的需求文档究竟是怎样的呢？

观点：从来不存在一份完美的需求文档可以满足任何程序猿的任何需求。

如果一定要一个答案，那么就是：

让开发小伙伴认同功能价值，充满成就感是PM最重要责任之一。实操角度看，从宽度（关联性）、深度（逻辑性）、长度（预见性）、量度（价值数据化）4个方面出发去描述需求，文档自然可以画的清晰、写的明白。

从下面3个角度分析：

程序猿也需要画像区分：

不喜欢任何文档的程序猿。 这类小伙伴记忆力强、理解力好，只要PM说一遍就可以很快理解业务逻辑，想的比PM可能都细致。

对于这类成员，PM的需求文档力求主业务逻辑清晰，比如开通个人委托扣款的前置条件具体有哪些条件；TA系统进行补单的几种业务逻辑情况。设计与交互上的逻辑为辅。

喜欢流程图多过文字与原型的程序猿。 这类小伙伴对于图形有特别偏好，你给他看一堆原型跟文字描述，他会觉得不耐烦。对于这类成员，我们一定要保证流程图的模块完整性、逻辑准确性。原型与文档可作为一些设计与交互逻辑的辅助参考资料。

只喜欢文档原型且较少交流。 他只想安静的做个Coding的美男子。如果是这类，那么我们就需要准备齐全，图、原型、文档，缺一不可。

啥都不喜欢，只喜欢挑刺。 接着往下看，当你做完文末部分就可以好好沟通了。

通用逻辑：原型与文档并重，功能结构图与页面结构图为首，流程图为辅。

1. 目前前端产品设计目前比较主流的方法论有：场景论、数据论、功能论、设计论。无论哪一种方法论前端产品就是给C端用户看并且使用，所以原型跟文档不可缺少。

2. 这里额外提一句关于原型、文档的格式。我在刚从业1年的时候，一直纠结原型与文档是否一并写入在Axure。这点不重要，尊重开发团队的习惯就好。

3. 当年我在金生宝就使用Axure＋Word，到了金大师后台主要用Axure为主。对于一个优秀的PM，这些都是常用工具，需要做到用什么都可以。

4. 如果你有自己常备的一套Word与Axure文档模板当然会更加高效。

通用逻辑：流程图、时序图、架构图、数据表为主，文档次之，原型为辅。

1. 后台产品设计主要方法论有：业务流论、效率成本论、性能论。主要面向企业内部用户，目的是提升企业整体效率：人的效率与钱的效率，包括获客效率、服务效率、管理效率、信息流转效率等，对于感性体验没有C端产品那么苛刻，而对于逻辑与数据会加强。

2. 通过图、表更能便捷、快速的反映基于业务流的本质。一张图表现的东西，可能用10个原型页面都未必能画清除。

复杂的2C、2B功能文档

1. 抄家伙

2. 业务流程图、系统交互图、信息流图、资金流图为主

3. 功能列表、页面结构表次之

4. 原型最末

宽度、深度、长度、量度

如何让需求文档考虑更周全？我们从4个角度来说：

这在开始比较困难，有以下几个方法可以让我们逐渐做到。

1. 重要业务关联模块梳理。当产品功能越多，那么新增一个功能就有可能对原有功能产生影响，这就是我们所谓的看得见的耦合。看不见的耦合是在代码层面。所以平时一定要多关联业务模块有更多了解。

2. 重要业务流节点梳理。无论是前端还是后台产品，都会有1、2条主要的业务流（人体脊柱），这些业务流中的关键节点类似人体的脊柱节点。在功能规划设计的时候，提前需要考虑到。

3. 高内聚低耦合的设计理念。我非常喜欢内聚、耦合两个词，好的设计规划方案可以大大减少开发小伙伴的工作量，便于功能、代码扩展、重构。

4. 如果业务逻辑的分离不够导致耦合，则会导致产品功能逻辑耦合在一起，进而使得代码逻辑耦合在一起，对于扩展、重构就是件很蛋疼的事情。这个设计理念可直接评价一个PM的逻辑、抽象、规划水平能力高低。有机会我详细再写一篇。

深度：100%的逻辑清晰程度

1. 产品逻辑可以简单类比成代码中的输入于输出关系。我的习惯是画流程图避免逻辑上的遗漏。

2. 如果文档中出现思虑不周的情况，而技术小伙伴已开工，根据我的经验，不要去弥补这个逻辑的漏洞轻易衍生出新的逻辑。有些漏洞是因为不重要，所以PM会遗漏，如果不重要那么就放在下个迭代进行优化。

3. 不要老搞幺蛾子变动，尤其是已经定稿的开发逻辑。一定要改变，PM自己先想清楚是否会影响到其他功能。

长度：50%的预见性

1. 从0到1，从1到10，从10到100，是产品的不同阶段。PM有时像一个军师需要运筹帷幄。根据市场情况、竞争环境、公司情况、团队能力、产品成熟度决定什么时候做什么功能，做到什么火候，都是需要提前考虑的。

2. 这点也是直接评价一个PM水平能力高低的主要依据。当然也有一些天才，可以天马行空设计出一些惊才绝艳的产品，在我看来，他们更有预见、洞察的能力而非胡思乱想的涂鸦之笔。

量度：100%的价值数据化

1. 功能价值数据化，让开发小伙伴认识到他们的每一天、每一分钟、每一秒都是在做一件有意义、有意思的事情。

2. 与团队达成一致的愿景、使命、价值观，不断沟通，反复沟通。让这些深深印刻在团队成员心中。

3. 让开发小伙伴更有成就感，为他们扫清前进道路上的所有障碍。与他们站在一起，体谅他们、给他们更积极的反馈。即使在高强度、高压力的环境下，尽量为他们创造快乐、开心的工作环境。

我们跟开发小伙伴是一个团队，重要的不是需求文档，而是如同一个战壕的战友，我们将后背交给对方是因为信任。追求真实、互相信任，因为信任所有简单，因为简单所以高效。如果不是这样，再好的需求文档又能怎么样。

— End —