[答朋友问] 从开发人员的角度看，好的需求文档应该是什么样的？

[ShannonChenCHN]

No description provided.

[ShannonChenCHN]

需求文档对我们来说，意味着什么？

1. 减少沟通成本，一个项目的的效率包括两个方面，项目流程和研发效率，研发效率是各技术团队内部自己的事，各个团队自己可以花时间去搞定，但是项目流程上就不那么简单了，需要大家的共同努力。
2. 需求文档本身就是一个产品，需要不断改进，写给开发和测试看的文档，可以把他们当用户，如果用户自己用的不爽，说出来不好在哪里，我们也可以及时改进，就怕大家不愿意提意见。

如何从技术的角度去看待一份需求文档

1. 整体性。
   规范化管理，有备案，有据可依。不论是新功能也好，还是版本迭代也好，一个项目应该是有一个生命周期的，不断进化的，有文档备案的，比如，我们之前会员页由 h5 改为原生，很多逻辑和规则都没有文档可查，在开发、测试过程中也浪费了大量时间去沟通，后期产品同学自己估计也很难去理清楚，加上人员流动，情况就更遭了。
   理想情况下，后期的版本迭代过程中的文档，也是基于原来的文档更新的。

另一方面，是考虑到信息集中管理的问题。主要是因为之前在 jira 上每次提需求都是一个单独的需求配一张图，实际上是把一个完整的项目拆散了。这样就导致，我们在阅读需求和项目管理时，一是读的时候需要打开很多不同页面去找，最理想的效果是，你一说什么，我们大家马上知道都去哪找，而且很快就能找到，二是不方便把这些需求联系起来，很多情况下一个大的需求里的各个小需求是互相穿插的，比如之前的复活招牌菜。

2. 逻辑清晰，关键逻辑最好配上流程图，有些不容易理解的地方，最好注明设计意图，告诉开发和测试你想要的究竟是什么，为什么这么设计，如果 PM 同学都不知道，那么作为下游的开发和测试，也会搞得晕头转向。

3. 信息维度：展示（比如服务端要提供哪些字段，前端的展示规则要提供各种情况的示意图，布局样式）
   交互（比如点击跳往哪里、热区范围，有没有下拉刷新，h5 中要不要判断是否要跳转到 APP ）
   是否需要动态配置
   边界条件（比如超出一行怎么显示，有些可能要跟 ued 同学沟通下）
   备注说明（比较特别的地方最好说明一下为什么这么设计，后面有不有可能改，有可能改成什么样，这就相当于打了个预防针）

4. 表现形式：word 也好，HTML 文档也好，wiki 也好，这些只是展现方式。最重要的还是内容本身的可读性，最好以图片为主，粗稿画个原型图可以接受，但是后面最好替换成最终的 UI 稿，如果有改动及时更新图片和文档，并高亮显示，wiki 下面写备注并不是一个好的选择。

5. 尽量详细，至少保证一些基本信息要完善，如果是通用的规则可以直接单独说明。原则是，你至少要讲清楚你要的是什么。比如要加一个轮播图，就要知道轮播图图片尺寸，图片来源，上传规则，自适应规则，怎么跳转，跳转的目标是否可动态配置

很多时候开发估时估不准，是为什么，一方面是需求不明确，另一方面就是估的不够细，因为需求列的不够详细啊，当然开发自己也有一部分原因。比如之前的会员频道由 h 5 改成原生，页面上看上去很简单，PM 和 ued 同学都觉得只要把 h5 照搬过来，大概改一改就行了，实际上，这里面有很多逻辑，就拿城市切换来说吧，第一眼看上去不就是一个切城市的按钮吗，点击切换不就 OK 了吗？但是后来做的时候才发现这里面差不多有 10 多种情况，所以很多时候，表面上看上去很简单，背后的逻辑却不简单。

6. 其他
   命名要统一，比如之前出了个新的会员中心，这个时候有同学就把老的和新的搞混了，如果有人及时做了声明，后面就可以大大避免这种信息不统一的问题了。

注：以上纯属个人观点，仅供参考，希望能够帮到你，有问题随时欢迎交流。

[ShannonChenCHN]

延伸阅读

• 产品经理如何撰写PRD文档
• 产品经理必读：PRD文档详细解析
• 产品经理实习生怎样提高文档书写能力？
• 作为一名优秀的产品经理您知道常用交互文档的写法吗？