需求制定、描述与交付是产品经理最基本最基本的技能之一。这件事是否做好，决定了开发是否高效，进一步说甚至影响产品与开发的关系。
如果产品的需求描述有误，必定导致程序开发走上一个错误的方向。而程序开发走在错误方向上时，一般都只会在开发完成验收产品后才会发现功能开发与需求原意不符。这时候再让开发返工重做，必定会为开发带来巨大的麻烦，工作量大不说，很可能还会遇到巨大的时间压力，还可能因此而导致同事关系恶化（老是要开发返工重做、调整代码，开发肯定想砍人啊！）。
那么，在需求制定有什么需要注意？如何做好需求制定、描述与交付呢？需要注意以下关键点。
1、从程序角度把握需求的本质
大多数语言都是面向对象语言。在这些语言中，需求的本质就是描述清楚涉及对象、以及对象之间的相互关系（方法），以及对象作用前、作用后的属性数据存储（数据存储）。把需求拆分为这三个方面，基本上可以把需求清楚描述，把我需求的实现代价以及存在的技术风险。
2、需求描述完成后需要与相关开发人员沟通
需求描述清楚后与相关技术人员沟通很重要。技术人员与产品经理永远都是处于一个信息不对称的状态下。
（1）程序员可能无法理解需求的来源以及为什么这个需求一定要这样做。这时候把需求抛出来与大家一起讨论，让涉事人员批评指正，很可能从业务上、需求本身发现不合理之处。若果相关质疑言之有理，则需要及时调整需求。
（2）产品经理永远无法知道产品实现技术中的所有细节。即使需求本身从商业上、用户价值上是合理的，但也未必就代表这个需求能够顺利实现。因为产品经理对很多技术细节可能是不了解、甚至不理解的。跟程序员沟通，然他们指出需求中的逻辑冲突、实现代价和实现风险，进而再对需求进行调整。
3、需要清楚描述需求调整的背景
尽管完成上述1、2还远远不够，有一次我就遇到了这种情况。
产品：看看明天进行版本更新
开发：可以，但现在再重构，明天更新有点麻烦
产品：嗯，那看吧尽量更新
（次日，程序员完成了系统的更新）
产品：更新好了就可以，这次更新最主要是修复一个XXbug
程序：啊？。。。你早说啊，如果这侧更新只是为了修复这个bug，我可以单独修复啊，不用停止当前的重构进程。（话毕，这位程序媛拿起了一把西瓜刀
产品需求的本质是满足用户或某种场景的需求。我们在描述需求的时候既要把需求的细节描述清楚，更要把需求的目的描述清楚。因为只有把目标描述清楚，其他人才能够判断这些需求细节（逻辑、流程等等）是否达到需求目标的最优途径。如果需求描述中的不是最优方案，开发人员可能会根据技术情况提出一些更简单和有效的方法以解决问题，提高开发效率。
4、需求描述与交付一定要善用举例子
流程图诚然是一种很好的需求描述的方法。但是某些情况下还不足够，比如某些需求涉及的要素未有名词表示，自创名字又会让需求描述变得晦涩难懂。这是最好就用举例子的方法，程序员能够从例子中抽象出程序语言，然后对需求点进行一一实现。
本文只是个人的日常总结和所思所想，文笔拙劣，欢迎讨论和批评指正！
