需求之所以复杂就是因为需求是人来做的，如果是机器来做就太简单了：只要输入正确的命令，机器会准确的帮你实现好。
产品看似掌控大局，但是很多事情都不是自己能完成的，发需求成了差评的日常，给设计发，给技术发，给策划发…需求发出去之后，收回来的东西不满意也是常有的事情，于是吐槽也成了日常，然而吐槽也并没有什么卵用…
金玉良言：所有问题都是自己的问题！别吐槽！想想我能做什么！
提需求的3大要点
下面说明3个提需求的要点：
一、需求是人做的，人心是肉长的
需求之所以复杂就是因为需求是人来做的，如果是机器来做就太简单了：只要输入正确的命令，机器会准确的帮你实现好。有了人的存在，需求就会存在delay、错误、品质不够等问题。但这并不能成为需求实现不理想的接口，为何别人的需求可以加塞在你的前面？为何别人提的需求实现品质就比你的高？同一个忙，你找陌生人，朋友，亲人来帮，其过程和结果肯定是不一样的！那你能不能让对方成为你的朋友甚至哥们，就要看你的本事了。
二、发需求的方式
我相信所有人都经历过这么一种场景：
你发了需求，但是对方没有看到，于是在交付的那天你什么都没有收到！别怪别人！怪自己！
发需求的方式强烈建议2种结合：邮件 口头
邮件：很正式，内容完整，并且容易回溯
口头：最好是口头，因为消息和邮件是繁多的，很容易被忽略，但是语言的交流是印象深刻的。如果无法实现口头交流，最好是通过IM再提醒一下，让对方明确的回复已经看到邮件，加深印象。
三、需求内容需要符合“SMART原则”
Specific——需求必须是具体的，明确的，别摸凌两可
Measurable——需求必须是可以衡量的，要能够评价他的好坏
Attainable——需求必须是可以达到的（这个也是对方经常拿出来的理由，遇到之后参见要点一）
Relevant——需求必须和其他目标具有相关性，没有意义的需求是浪费时间，要告诉对方意义何在
Time-based——需求必须具有明确的截止期限
SMART原则非常实用，如果想详细的了解这个原则，可以点击这里——SMART原则 via MBA智库
技术需求怎么提
给技术提过需求的都有过类似的经历：
为什么需求这么简单，但是技术做出来的东西还是有问题？
我的需求文档已经很详细了，为什么不按照文档里的来做？……
这些所有的不愉快往往都跟自己提需求的方式有很大关系，而不能只怪技术同学！
下面就对比一下错误的提需求方式和正确的提需求方式：
错误的姿势
错误的方式：
脑袋里想好要什么
将想要的东西写成需求文档
将需求文档发给技术去做
等结果
错误的方式往往都是错误的观念导致的。
错误的观念：技术是干活的，只需要按照我说的做就行了，不需要你自由发挥。大部分给技术提需求的人都不是技术出身，对技术并不了解，如果技术沦为一个纯执行，那么就成了“外行指导内行”，何况技术部门又不归产品管，自然有很多矛盾存在。另外，我们脑海中想要的东西写到文档中一定无法100%的还原，技术再去看这个文档，理解过程又有一定折损，就导致我们想的和最终做出来的东西相差甚远。
核心问题：产品和技术之间信息是不对等的！每一步过程都有信息折损，导致了最终产出不理想。
正确的姿势正确的方式：
不聊技术聊业务，先让技术同学充分的理解业务流程是什么，技术在业务中间的作用是什么
在技术同学理解业务的基础上共同讨论解决方案，列出可行的方案
业务人员和技术人员综合各种因素选择一种适合当前的“最佳方案”
双方达成一致后再最后形成文档
文档中包含前端表现细节和后端流程图（想了解文档怎么写可以百度一下“PRD”）
核心问题改进：
让技术同学充分的参与进来，一同商量，确保在方向性上大家高度的保持一致！
业务同学的解决方案不一定是最佳的，所以要发挥技术同学的优势，让他们也来出方案，讨论方案。
不要在一棵树上吊死！方案细节不着急展开，先多出方案，然后再评估方案，确定方案
设计需求怎么提
说到设计就需要强调一下前文说到的“人心都是肉长的”，设计人员非常感性，关系好图就做的好，心情好图就做的好。
所以设计需求的重点不在于提需求的时间点，而在于平时关系和感情的积累！
设计和技术的差异
下面把设计和技术来对比一下，让大家有一个直观的感受：
下面就是具体的建议了：
给设计足够的提前量
“这个需求今天就要！”这句话谁听到谁不爽！
大部分需求都是可以腾出足够的提前量的，如果渠道没有主动给你，你就主动去要。要过的需求定期整理和更新（毕竟没有哪家是每天改版玩的）
时间越多，图的效果就会越好！
优化流程，避免返工
设计最烦的就是做好的东西白做了，所以一定要避免返工。
在大批量改尺寸之前一定要把好关，不过关的图就不要改尺寸，直到所有相关人员（项目组，运营，市场，老板，渠道方）都过目了，都点头了，再开始改尺寸。一旦开始改尺寸了就不要BB了，改完就得用。如果任何人在任何时间都能否决设计，那设计就会做大量的无用功。
