对于互联网项目来说，第一步是要做什么呢？
如果比较专业的肯定会回答你，肯定是做市场调研啊，搞搞MRD，BRD什么，搞明白了自己要做什么。
然而对于现在大多数互联网企业或者称之为刚刚从传统企业转型的互联网新贵来说，做一个份产品的需求才是真正他们需要的。
在这里我先说一个故事，故事的主人公是我的一个朋友。最近他们公司开始要涉足一下互联网，这是很多传统企业准备和喜欢做的事情，于是他们公司找了一家外包公司来做这个事情。有一天他说他很忙，要去外包公司对接项目，也是这个时候我才知道他们公司是安排他在做这个“产品经理”。一个从来没有接触过互联网的人来做产品经理，看似完全没有道理的事情，但是我相信这个事情绝对不是个例。
所以今天这篇文章不是写给大神产品，小神产品或者是入门产品看的，因为你们可能对需求的理解比我还深入，所以我只是献丑的给那些完全是新手的产品经理写下这份东西，希望能够共勉，也希望能够真正的帮助到你们。如果大家觉得我写得差，欢迎给出意见指出。
一：什么是需求？
我们首先来明确一下需求到底是什么？是给谁看的？
这里我们来解释一下不同的需求文档。
BRD文档
BRD文档从字面的意思是“商业需求描述”，是探讨产品的市场价值的东西，是给老板看的。
MRD文档
MRD文档从字面的意思是“市场需求描述”，是探讨产品市场的东西，是给所有参与项目的人看的。
PRD文档
PRD文档从字面的意思是“技术需求文档”，是描述产品研发的东西，是给研发部门人看的。
而在大多数的人看来，需求文档指的便是PRD文档，说得简单明白一点就是告诉技术人员怎么开发这个东西的文档。
而今天，我们主要讲一下PRD文档。
二：开发模式之谈
在诉说PRD文档的形式前，我们要讲述一下和PRD文档发展息息相关的东西—–开发模式。
在我们大家的印象中，最为熟悉的开发模式有两种，一种是瀑布的开发模式，一种是敏捷开发的模式。这里我们先来说明一下瀑布开发和敏捷开发到底是什么？
瀑布开发：
如图所见，瀑布流开发是一个完整的非环形开发模式，旨在一次性进行完整产品的设计和开发。成本较高，周期较长，但是项目需求的问题则非常小，后期维护的成本较低。
敏捷开发：
如图所见，敏捷开发是一个环形开发模式，旨在快速的迭代，简化的进行开发。成本较低，周期较短，但是项目需求的问题则比较大，后期维护的成本高，或者说，敏捷开发是一种一直持续的过程，而不存在后期维护的说法。
两者区别：
然后我们再来看看我找到一张图来说明两者之间的区别，我觉得很形象。
瀑布开发就是传统开发，是一大堆文档后进行开发最后变成一颗大树，而敏捷开发则是一步一步的成长成一朵成熟花朵。
总结来说就是瀑布开发是前期花很大一段时间来进行项目需求的讨论，形成非常标准以及专业的文档来进行开发。而敏捷开发则是设计开发同步进行，一边开发一边进行设计。
三：产品开发之谈
上一节介绍了两种不同的开发模式，这一节我们来说一说产品的开发到底选择什么样的开发模式是比较科学的。当然，这里的科学并不是完全科学，因为这个世界不存在完全科学的东西…..Orz。
在当今的互联网世界当中，人人都知道一点，对于一个产品最重要的是时间。古话说得好：“一鼓作气再而衰三而竭”。这个典故我相信经历过义务教育的人都知道是什么意思。对的，对内来说无论是研发团队还是产品团队亦或是任何一个职能团队来说，时间越长项目的风险越大。对外来说，一个产品久久不能上线面临的是市场的快速竞争和资本届的质疑。所以天下武功唯快不破的秘诀在当今的互联网世界是绝对的真理。
所以现在的互联网世界的产品开发更多使用的便是敏捷开发的模式，快速的版本迭代来解决上一个版本的问题。
这里套用我看到过的一句话：“产品的第一个版本只要主要流程能跑通，马上上线！”。
四：版本之谈
说完了敏捷开发，那么注定避免不了版本的问题，所以在产品一开始的设计时候，产品经理就需要对每一个版本进行一个初步的设计，研究产品节点，沟通开发周期。
那么问题来了，到底怎么来规划这个版本呢？
接下来就是小弟的愚见了，我们大致的可以把版本这么来划分：
第一个版本：主要流程。
第二个版本：优化主要流程。
第三个版本：根据运营数据增加功能。
当然，你可以不把他看成是第一第二第三版本，而是看成一个顺序，而对于刚开始做的产品，请牢记一句话“不要做太多的功能，你是做什么的，能让用户体验你这个了，就上线”。
五：需求形式之谈
说完了模式，谈完了版本，我们来说说最后的一个话题，到底怎么做PRD需求文档。
当然，今天我们并不讨论需求文档怎么做，那是技术活也是哈姆雷特，每个人写出来都是不一样的。所以没有应该怎么写，写成什么形式，也没有谁写得好，谁写得差。只要是研发团队看得懂的就是好需求。
可是，如果不用说怎么写，那还谈什么需求形式呢？
哈哈哈，我们这里虽然不谈怎么写需求，但是的的确确是要说一下需求的表现形式，接下来我给大家说一下常见的需求形式：
1.文档形式
故名思议，文档形式就是以文档的形式把开发的需求展示出来以供研发团队进行阅读。
Good：
文档形式的需求文档是非常详细的，当然如果水平不行也会出现漏洞，这里我们就忽略水平问题。
文档形式以文字描述项目的各个功能以及开发的流程，对于任何一个研发团队来说都是能够轻松阅读，并且对于项目的验收可以作为很有效的验收工具。
Bad：
坏处就是，太难读了。
我敢保证，现在90%的研发团队成员看见需求文档头都是大的，而且受限于技术水平，在文档上描述的时候会存在理解上的误读。
还有就是，形成文档形式的需求对于项目设计人员来说是需要比较高的要求，也需要很长的时间才能做好的。所以世面上你只听说过“线框仔”而没有听过“打字仔”。
2.原型形式
原型我就不多说了，原型设计的出现是很早的事情了，具体想了解的话去百度吧！原型呢就和我们小时候写的看图写话一样，一张图描述出我们要做什么，简单易懂。
Good：
原型这个东西，效率高，描述准确，理解误差小。而且能很好的直接进行操作，还原设计流程。
而且原型上手快，当然，你要做到很牛逼，那还是很难的。
Bad：
细节上的描述对于原型来说还是差强人意，需要进行非常高保真的原型设计才能完美重现细节设计，这对于原型制作者的要求比较高。
其他坏处我暂时还没有想到，希望大家可以补充，哈哈哈！
注：下面我们就不进行优劣对比了
3.文档+原型形式
这个是什么，我就不说了，你要是这个都不知道话，请你给我打电话！
这种表现形式可以说是当今开发界最完善的开发形式了，不但在可视化上进行了描述，也在文字阅读中进行了描述。对于流程，页面的细节也是很能把握到位，而唯一的缺点就是需要花费的时间比较长。按照现在产品开发的周期来看的话，除非产品经理不吃不睡，才能不耽误开发进度！真的，做过的人才知道。
所以，我们说完了三种展现形式，这个时候选择哪一种就需要产品经理自己考虑了，而推荐几点参考标注：
产品开发周期。
技术团队水平。
产品经理水平。
好了，今天的文章就写到这里。总而言之就是大概的介绍了一下需求这个东西，也没说什么有营养的话，权当看着好玩吧。
如果有什么写得不好的地方，请发送给我邮件督促我改进，谢谢各位看官。
