给技术提过需求的都有过类似的经历：
为什么需求这么简单，但是技术做出来的东西还是有问题?
我的需求文档已经很详细了，为什么不按照文档里的来做?
……
这些所有的不愉快往往都跟自己提需求的方式有很大关系，而不能只怪技术同学!
下面就对比一下错误的提需求方式和正确的提需求方式：
错误的姿势：
错误的方式：
1.脑袋里想好要什么
2.将想要的东西写成需求文档
3.将需求文档发给技术去做
4.等结果
错误的方式往往都是错误的观念导致的。
错误的观念：技术是干活的，只需要按照我说的做就行了，不需要你自由发挥。
大部分给技术提需求的人都不是技术出身，对技术并不了解，如果技术沦为一个纯执行，那么就成了“外行指导内行”，何况技术部门又不归运营管，自然有很多矛盾存在。
另外，我们脑海中想要的东西写到文档中一定无法100%的还原，技术再去看这个文档，理解过程又有一定折损，就导致我们想的和最终做出来的东西相差甚远。
核心问题：运营和技术之间信息是不对等的!每一步过程都有信息折损，导致了最终产出不理想。
正确的姿势
正确的方式：
1.不聊技术聊业务，先让技术同学充分的理解业务流程是什么，技术在业务中间的作用是什么
2.在技术同学理解业务的基础上共同讨论解决方案，列出可行的方案
3.业务人员和技术人员综合各种因素选择一种适合当前的“最佳方案”
4.双方达成一致后再最后形成文档
5.文档中包含前端表现细节和后端流程图(想了解文档怎么写可以百度一下“PRD”)
核心问题改进：
让技术同学充分的参与进来，一同商量，确保在方向性上大家高度的保持一致!
业务同学的解决方案不一定是最佳的，所以要发挥技术同学的优势，让他们也来出方案，讨论方案。
不要在一棵树上吊死!方案细节不着急展开，先多出方案，然后再评估方案，确定方案。
本文来源：上方网
