程序员到底需要一份什么样的需求文档？

2017-04-18 10:15:00

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

前言：大家好，我是陈峰，目前负责金大师（黄金TD业务）企业应用产品线。以下内容主要基于我在金大师产品研发团队的反思与总结。

如果一定要一个答案：

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

从下面3个角度分析：

1. 因人而异

程序猿也需要画像区分：

不喜欢任何文档的程序猿。这类小伙伴记忆力强、理解力好，只要PM说一遍就可以很快理解业务逻辑，想的比PM可能都细致。对于这类成员，PM的需求文档力求主业务逻辑清晰，比如开通个人委托扣款的前置条件具体有哪些条件；TA系统进行补单的几种业务逻辑情况。设计与交互上的逻辑为辅。
喜欢流程图多过文字与原型的程序猿。这类小伙伴对于图形有特别偏好，你给他看一堆原型跟文字描述，他会觉得不耐烦。对于这类成员，我们一定要保证流程图的模块完整性、逻辑准确性。原型与文档可作为一些设计与交互逻辑的辅助参考资料。
只喜欢文档原型且较少交流。他只想安静的做个coding的美男子。如果是这类，那么我们就需要准备齐全，图、原型、文档，缺一不可。
啥都不喜欢，只喜欢挑刺。接着往下看，当你做完文末部分就可以好好沟通了。

2. 因功能而异

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

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

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

后台产品设计主要方法论有：业务流论、效率成本论、性能论。主要面向企业内部用户，目的是提升企业整体效率：人的效率与钱的效率，包括获客效率、服务效率、管理效率、信息流转效率等，对于感性体验没有C端产品那么苛刻，而对于逻辑与数据会加强。
通过图、表更能便捷、快速的反映基于业务流的本质。一张图表现的东西，可能用10个原型页面都未必能画清除。

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

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

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

重要业务关联模块梳理。当产品功能越多，那么新增一个功能就有可能对原有功能产生影响，这就是我们所谓的看得见的耦合。看不见的耦合是在代码层面。所以平时一定要多关联业务模块有更多了解。
重要业务流节点梳理。无论是前端还是后台产品，都会有1、2条主要的业务流（人体脊柱），这些业务流中的关键节点类似人体的脊柱节点。在功能规划设计的时候，提前需要考虑到。
高内聚低耦合的设计理念。我非常喜欢内聚、耦合两个词，好的设计规划方案可以大大减少开发小伙伴的工作量，便于功能、代码扩展、重构。
如果业务逻辑的分离不够导致耦合，则会导致产品功能逻辑耦合在一起，进而使得代码逻辑耦合在一起，对于扩展、重构就是件很蛋疼的事情。这个设计理念可直接评价一个PM的逻辑、抽象、规划水平能力高低。有机会我详细再写一篇。

产品逻辑可以简单类比成代码中的输入于输出关系。我的习惯是画流程图避免逻辑上的遗漏。
如果文档中出现思虑不周的情况，而技术小伙伴已开工，根据我的经验，不要去弥补这个逻辑的漏洞轻易衍生出新的逻辑。有些漏洞是因为不重要，所以PM会遗漏，如果不重要那么就放在下个迭代进行优化。
不要老搞幺蛾子变动，尤其是已经定稿的开发逻辑。一定要改变，PM自己先想清楚是否会影响到其他功能。

从0到1，从1到10，从10到100，是产品的不同阶段。PM有时像一个军师需要运筹帷幄。根据市场情况、竞争环境、公司情况、团队能力、产品成熟度决定什么时候做什么功能，做到什么火候，都是需要提前考虑的。
这点也是直接评价一个PM水平能力高低的主要依据。当然也有一些天才，可以天马行空设计出一些惊才绝艳的产品，在我看来，他们更有预见、洞察的能力而非胡思乱想的涂鸦之笔。

功能价值数据化，让开发小伙伴认识到他们的每一天、每一分钟、每一秒都是在做一件有意义、有意思的事情。
与团队达成一致的愿景、使命、价值观，不断沟通，反复沟通。让这些深深印刻在团队成员心中。
让开发小伙伴更有成就感，为他们扫清前进道路上的所有障碍。与他们站在一起，体谅他们，给他们更积极的反馈。即使在高强度、高压力的环境下，尽量为他们创造快乐、开心的工作环境。