保护产品汪，拒绝砍需求
Round 1
产品：开发个富文本编辑器，让用户能自由发言！
开发：滚！
Round 2
产品：在下有一个需求不知当提不当提…
开发：在下有一句MMP不知当讲不当讲…
Round 3
产品：……需求就是这个样子
开发：做不了
产品汪最寂寞的事，就是需求评审会变成技术讨论会；产品汪最悲催的事，莫过于需求评审会开到最后开成了需求被砍会，不是技术实现不了了，就是性价比太低。砍来砍去，只剩下几个简单的小需求。本是同根生，相煎何太急啊，一周做辣么点需求，真的能写满周报吗？？你们的良心不会痛吗？？
额，与其谴责程序猿的良心（还有这种东西？），倒不如自己搞清楚正确的提需求姿势！老K根据自己多年的提需求经验（被砍过的需求连起来能绕地球一圈儿），经过长达半个月的总结（是的，我之所以半个月没更新不是懒，是在总结），终于写出了这本葵花宝典之正确的提需求姿势——不用自宫也能练！
- 首先，确定你不是瞎B提需求
- 然后，再确认一遍1
- 最后，再确认一遍2
所谓需求，就是满足用户的需求所要做的功能。由于产品汪们一直自诩是代表用户，站在用户的立场说话，所以通常叫做“需求”。好的需求会有明确的目的，要么是满足用户的某种需求，要么是实现公司的某种目的。这个目的，不只是需求的出发点，也是方向。当有围绕需求展开的细节难以确认是，都可以以目的为导向，做出判断。
在需求评审会上，开发问为什么做这个需求，如果你能结合用户需求以及公司目的阐述充分的理由，需求被砍的几率就会大大降低。
接下来就是简单的套路了：比如某期版本迭代要做需求A/B/C,老K通常会排上A/B/C/D4个需求，然后在需求评审会上忍痛（敲黑板，跟我念：忍痛！）放弃需求D，让程序猿们开开心心的去做ABC，最后在心中默念：笑年郎，还是图样啊。
一个完整的需求，最基础也要具备：流程图、原型图和文字注释。最完美的效果是，给程序猿讲过一遍需求之后，他们在开发过程中再也无需问你，所有的疑问都能从需求文档中得到解答。要达到这种境界，单纯听老K在这BB是不可能的，需要各位在工作中不断地总结、优化以及迭代。
常言道：懂得了很多道理却依旧过不好这一生。学习了很多拳法，实战中不依旧是王八拳？读完老K的文章，了解了正确的提需求姿势，真正运用起来了，其实并不见得每次都有效。
想要立竿见影，那就得使出绝招：真正的正确的提需求姿势：
-end
关注公众号：产品经理日记（ID：p_m_diary）回复“PRD”，获取鹅厂内部需求文档模板！
