产品吐糟：我写的需求文档还需要程序员评审，这正常么？

在互联网软件公司，每个公司都会自己的文化，比如有的公司的是产品主导整个项目，有的公司则是技术主导整个项目，比如谷歌公司，好多项目都是技术在主导，公司对技术足够的重视，这样的现象除了与公司的文化有关，想必与每个人的情况有关，比如公司来了一个比较优秀的产品经理，也有很牛的技术背景，主导过大的项目开发，那自然就会选择产品主导项目，目前的情况看，相当一部分公司，产品起主导地位，是整个产品的主人，近期，一名产品经理网友却吐糟了他遇到的一些现象。

据这名产品经理所说，他头一次遇见下面的这种现象，那就是产品经理要把每个功能的价值写在产品的需求文档里，好让每一位技术人员进行评审，他个人感觉这个有点不正常，不过，我想程序员看了之后心里会窃喜吧，产品总是指挥你们干这干那，现在轮到你们对产品的需求进行评审了，当然，这是一项工作，评审也是不能随意去评，是要用心的，针对这样的案例，让我们先看看其他网友们都是什么观点吧！

网友一：不需要在文档里写这些，但是需求点的来源价值等必须在需求评审的时候就聊清楚，很多时候有些需求确实就是伪需求。评论里一些人在说什么谁主导的问题其实观点就不对，一个好的team就是需要共同去打磨产品的，而不是纠结谁主导的问题

上世是朵花：认同部分观点，一个好的产品需要大家共同参与，好的产品也不是一次性就设计好的，也是经过多次打磨的结果！

网友二：学习下怎么写用户故事吧，不是为了画饼，是为了更好的让开发理解这个功能是在什么场景下，给谁用的，能够解决什么问题，有益于研发做开发

上世是朵花：没错，了解项目背景对研发来说是非常重要的一件事情，这样在开发的时候目标也比较明确，做出的功能就不太可能偏离需求。

网友三：功能价值肯定要写啊，难道拍脑袋的功能，rd也要负责实现？如果前期没有数据支持，也需要说明白上线后会补充提供。

上世是朵花：有相当一部分情况，由于各种因素好多产品经理这方面做得并不够完善，其实能写清楚功能价值还是比较有用的，让具体实施的人更能明白他做东西的价值。

网友四：产品向研发汇报？你这个产品的位置有的低啊

上世是朵花：这样的说法就有点幼稚了，这样的解读是故意拉仇恨的不是么？应该多想想这么做的意义是什么。

网友五：不正常，难道需求价值是开发评估？这也不是开发擅长的领域吧，开发更多关注技术难度和实现时间

上世是朵花：功能的价值是产品写的，开发的评估更多是站在技术角度来说。一个事情，从多个角度去看会更好一点。

网友六：给搬砖的解释为何要盖楼？

上世是朵花：你把程序员比作搬砖的，有思想有抱负的程序员们，估计看到这个比喻很受伤。

网友七：需求背景有必要说明，是为了确保在大方向上保持目的一致。方案层面应该是产品提出，开发评估可行性和提建议，可以商讨，但是决策的角色应该是产品，各司其职。

上世是朵花：认同这名网友的观点，产品经理对产品的方案肯定是主导的，所有人都可以参与产品方案的一些细节。

网友八：不正常，但是对于常年被产品坑，满足一些朝令夕改，拍屁股提出来的需求的码农来说。只想说该！

上世是朵花：看来，这名程序员网友对产品的意见比较大了，还是要多多沟通，也许并不小像你想的那样。

一般，看到这种情况不多，由于项目时间紧，为了尽快上线，大多数情况只是介绍一下项目的背景，不会将每一个功能的价值都详细列出来，但是仔细想想，这样做也不是没有价值，虽然产品经理辛苦一点，花了些时间，但时对于程序员来说，能更明白所做东西的意义及价值所在，也是比较有用的，不过现实情况中，有一小部分程序员，有一个比较不好的习惯，看需求文档从来都不是那么认真，做东西只是听产品经理说个大概，具体实施的时候就是根据自己的想象来，那么做出来的东西很有可能与需求文档中有一定的出入，这种习惯是非常不好的，想必对以后的发展也是有一定的影响的，因此做一名优秀的程序员，不但要开发好自己的功能，而且还是要参与需求的规划，与产品经理们积极的沟通，让做出的产品体验更佳。

以上所有图片均来之互联网

大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！