不要侮辱研发的智商

最初接触需求分析是在大学，老师说需求文档和各种图画好了，最后码代码像是建楼房照着图纸码砖一样。工作后接触的第一个产品，做事十分谨慎的那种，最后的需求文档和设计稿每个细节都把控的很到位。举这两个例子是想说明产品人的基本素养之一是要确保给到技术的文档说明和其他是准确的，当然这只是一个美好的愿望。准确带来的各种好处，我就不赘述了。

然而实际情况是，产品自己弄好原型说明找研发，会有这样的反馈：这样做性能很差，我们服务跟不上；这个我们要开发很久；这个和历史功能有牵扯，改了会影响其他……总之研发想说这样做不行，然后产品进入沉思状，不死心还想再争取下。这个时候，你会怎么做呢？根据研发的反馈再想一个方案；评估可能性，按照原有方案，开发久一点也没关系……

和研发待久了，就是很想说一句：不要侮辱研发的智商。觉得这个时候正确的打开方式应该是从最开始的我们为什么做这个需求开始，抛开实现过程就业务讲清楚，末了加一句“我讲清楚了吗？”，确保大家都明白为什么这么做之后，问一句“大家有什么好的解决方法吗？”。技术说性能承受不住的时候，他们比较清楚是哪个步骤会很耗时，大家一起想一个现有基础上较合理的流程；技术说这个需求要很长时间的时候，很有可能是技术只关注了你需求描述，站在他们的角度完全可以用一个更简单的方法实现你要的效果；技术说这个需求和其他功能有牵扯的时候，你需要好好了解下现有的功能并考虑到需求里面。

以上都是切切实实经历过，如果你的打开方式不对，可以继续往下看。

需求文档里面有一个很重要的点就是需求背景和目的。刚开始的时候会觉得这个不是写给研发看的，研发从需求流程说明开始看就可以了。开需求会的时候，对需求的背景和目的也是寥寥几句，毕竟需求文档已经写得很清楚了，研发照着开发就好了。故事的开始都是美好的，可是故事不是你以为怎样就怎样。如果需求文档真的是完美到无懈可击，也许后面不会有很多问题，毕竟研发照着文档开发也不会有多大问题。如果需求文档并不准确，那所有的问题都会在开发测试的过程中暴露出来，这带来的结果就可能是项目延期或者最后上线和产品预期的不一致。问题总是有，我们总是希望前期把问题减到最少，在现有资源条件下让效果最大化。需求背景和目的十分重要，讲清楚这个，研发测试会从他们的角度发现问题，开发过程中遇到问题大家也能根据最终的目的提出其他对应的解决方案。

说了这么多就是想表达下研发都是很聪明的，千万不要觉得我要把需求写得十分完美，他们照着敲代码就好了。厉害的研发都是对业务有清楚认识的。

使用正确的敏捷