程序员说看不懂产品需求文档，你该怎么办？

增 删 查 改 显 算 传

增：数据会增加到怎样的一个量，当这些量增加到一定程度时页面需要怎样的表现形式。拿新浪微博的实时刷新来说，当微博条数持续增加，我们是按微博数量来固定分页，还是按照页面的长度来分页，还是根本就不用分页，持续的刷新下去，抑或是刷新和分页并存。

删：这个也是常规性操作，既然数据有增加，就会有删除的需求，哪些数据可以删，哪些不能删，删完之后数据会呈现怎么样形态等。

查：这是快速获得信息的一种方式，从繁杂的数据排列中准确定位出用户想知道的结果，通常会有好几种查询方式及查询条件，不管是哪种都要表现出来。

改：可分为两种来表现，一是用户对原有数据的修改，哪些可以哪些不可以，可以修改哪些元素，哪些元素一旦确定将不提供修改等；二是对设计的修改程序实现的方式，从一种方式更改为另一种方式程序是否易于实现。

一般来说产品经理做到以上四点就能把原型做的非常完善，假如数据做成了列表样式，是否考虑到了分页？是否需要排序？排序的话按什么 条件进行？排序满足不了需要的话是否需要搜索框？查询框？查看详细列表的打开方式是怎样的？本页操作还是新窗口操作？跳转之后需不需要跳回来？选择数据支 持单选还是多选？单选的话用下拉还是radio？如此等等细节交待的越清楚，和开发的沟通越少。

显：数据的显示，根据需要做哪些显示，显示的方式是怎么样的，不同用户的权限是否一样，不一样的话数据如何表现。这里的表现的是背后逻辑。

算：指计算规则，比如热门文章=点击数*1+评论数*2+分享数*3诸如此类的背后计算的数值。此类规则约定之后可以节约很多时间。

传：数据的传递，不同服务器之间的数据传递，考虑到用户体验的时候ajax的传递，还有一些api的数值传递等等。

如果别人看不懂，说明有问题了，没有别的办法，改！我是做技术出身的产品经理，因此特别了解程序哥哥。如果你写的需求里面存在很多不确定因素，那是无法实现的，或者不知道怎么实现。举个例之，你的需求里面没有业务流程，那么十个人就可以用十种流程来达到相同的目的，人家当然不知道你要怎么做。或者需求里面确实很多该有的业务规则漏写。再举个简单的例子，你的需求写了“要把查询出来的数据导出到Excel表格”，这样程序员也不知道怎么实现的。因为你没有说明以下具体内容：导出的表格标题是什么，包含哪些列，列的先后顺序是什么？太多的不确定因素，因此人家无法实现。

产品和研发两个部门之间的距离应该缩小再缩小，哪怕会有摩擦都是值得的。好的创意或许就在争吵中出现了，所以我认为如果两个部门一方面出现问题就该两者多协商，用上现有的模型进行解释，让研发知道产品想做什么，让产品知道研发哪里会有难关，调和两个部门产品经理起着至关重要的作用。

跟你分享下我日常被怼的经历：
某天，我们开发了一个充值功能，这个是对公充值的流程，需要用户提前汇款，然后输入充值金额和汇款单号，需要管理员验证之后通过。测试阶段的时候，测试妹子报了一个bug。问题是这样的，充值金额那里没有做数据校验，可以输入负值，然后管理员审核通过后，账户余额不增反减。开发怒回：需求文档里没有写要做数据校验。然后我无话可说，去面壁了