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

程序猿哥哥看完PRD的反馈。。。要哭了。。。

今天被技术哥哥整的无言以对。。。虽说这个功能是目前还没大红大紫的功能,但是已经是很多平台都有在做的功能了,技术不该不知道,只是换了一个垂直领域而已。。。没有很复杂。。。

现在我忍住了怒火。。。假装自己写的有问题。。。正在耐心苦逼的重新细化按照技术要求撰写的PRD,细化到流程。。。到技术哥哥能看懂为止。。。
0
分享 2017-05-26

4 个评论

增 删 查 改 显 算 传

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

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

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

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

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

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

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

传:数据的传递,不同服务器之间的数据传递,考虑到用户体验的时候ajax的传递,还有一些api的数值传递等等。
如果别人看不懂,说明有问题了,没有别的办法,改!我是做技术出身的产品经理,因此特别了解程序哥哥。如果你写的需求里面存在很多不确定因素,那是无法实现的,或者不知道怎么实现。举个例之,你的需求里面没有业务流程,那么十个人就可以用十种流程来达到相同的目的,人家当然不知道你要怎么做。或者需求里面确实很多该有的业务规则漏写。再举个简单的例子,你的需求写了“要把查询出来的数据导出到Excel表格”,这样程序员也不知道怎么实现的。因为你没有说明以下具体内容:导出的表格标题是什么,包含哪些列,列的先后顺序是什么?太多的不确定因素,因此人家无法实现。
产品和研发两个部门之间的距离应该缩小再缩小,哪怕会有摩擦都是值得的。好的创意或许就在争吵中出现了,所以我认为如果两个部门一方面出现问题就该两者多协商,用上现有的模型进行解释,让研发知道产品想做什么,让产品知道研发哪里会有难关,调和两个部门产品经理起着至关重要的作用。
跟你分享下我日常被怼的经历:
某天,我们开发了一个充值功能,这个是对公充值的流程,需要用户提前汇款,然后输入充值金额和汇款单号,需要管理员验证之后通过。测试阶段的时候,测试妹子报了一个bug。问题是这样的,充值金额那里没有做数据校验,可以输入负值,然后管理员审核通过后,账户余额不增反减。开发怒回:需求文档里没有写要做数据校验。然后我无话可说,去面壁了
匿名用户