流程图的虚线是什么意思_程序员到底需要什么样的需求文档?

PMCAFF(www.pmcaff.com)：互联网产品社区，是百度，腾讯，阿里等产品经理的学习交流平台。定期出品深度产品观察，互联产品研究首选。

外包大师(www.waibaodashi.com)：要外包，找大师。PMCAFF旗下高质量互联网外包解决方案提供商。外包大师服务号：waibaodashi365

作者：陈峰 PMCAFF会员 挖财卓越财富产品负责人

编者按：

众所周知程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的东西，那我们应该如何撰写一份程序员真正需要的需求文档来解决这个矛盾呢？

本文作者陈峰，曾经在金大师(黄金TD业务)负责企业应用产品线。他基于之前在金大师产品研发团队的反思与总结，从关联性、逻辑性、预见性、价值数据化4个角度阐述了他的观点和思考，以下为正文，欢迎阅读转发。

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

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

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

从下面3个角度分析：

1、因人而异

程序猿也需要画像区分：

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

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

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

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

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

2、因功能而异

前端产品

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

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

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

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

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

后台产品

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

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

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

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

(1)抄家伙

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

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

(4)原型最末

3、宽度、深度、长度、量度

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

宽度：考虑到90%的完整性

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

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

最后再说几点个人感悟：

• 记住，我们跟开发小伙伴是一个团队，重要的不是需求文档，而是如同一个战壕的战友，我们将后背交给对方是因为信任。

• 追求真实、互相信任，因为信任所有简单，因为简单所以高效。

• 如果不是这样，再好的需求文档又能怎么样。

参考资料

［1］陈峰. 反思产品如何成为核心 系列31. 2017-03-19

［2］陈峰. 浅论产品文档PRD怎么写 系列10. 2016-06-25

［3］邱岳. 公众号二爷鉴书

［4］张涵. 阿里1688后台产品部主管

点击阅读原文，获取5000个成熟解决方案

中高端求职 & 招聘，PMCAFF人才服务最懂你

=> alice.zhang@pmcaff.com