每个人都来产品经理【起点学院】，巴斯特实战派产品总监手把手系统带你学习产品，学习运营。
对互联网项目来说，第一步是做什么呢？
如果是专家的话会回答的吧。 一定在做市场调查。 通过MRD、BRD等，我知道了自己想做什么。
但是，对于现在刚刚从很多互联网企业和传统企业转型过来的互联网新贵来说，制作产品的需求真的很有必要。
我在这里先说故事。 故事的主人公是我的朋友。 最近，他们的公司开始加入网络。 这是很多传统企业准备和喜欢的事情，他们公司为了做这件事找了外包公司。 有一天他说他很忙，要把项目与外包公司对接。 这个时候，我知道他们公司排他地做这个“产品经理”。 虽然没有接触过网络的人成为产品经理看起来完全没有道理，但我相信这绝不是一个例子。
所以今天的这篇文章不是写在大神产品、小神产品或者入门产品上的。 因为对需求的理解可能比我更深，我只是提供了丑陋的东西，完全是给新手产品经理写了这件事。 请协助和协助。 如果大家觉得我的写法不好的话，请给我提意见。
一：什么是需求？
首先让我们明确一下需求是什么。 你给谁看的？这里介绍了各种需求文档。
BRD文档
BRD文档字面意思是“业务需求描述”，是对产品市场价值的探讨，是给上司看的。
MRD文档
MRD文档字面上意味着“市场需求描述”，是对产品市场的讨论，是给所有参与项目的人看的。
PRD文档
PRD文档字面意思是“技术要求文件”，是描述产品开发的，是给研究开发部门的门生看的。
对很多人来说，需求文档就是PRD文档，简而言之就是教会技术人员如何开发这个东西的文档。
今天主要谈谈PRD文档吧。
二：开发模式之谈
在诉求PRD文档的形式之前，介绍与PRD文档发展相关的内容——开发模式。在我们的印象中，最广为人知的开发模式有两种。 一种是瀑布的开发模式，另一种是敏捷开发的模式。 现在，让我来解释一下瀑布开发和敏捷开发到底是什么。
瀑布开发：
可见，瀑布开发是一种完整的非环状开发模式，旨在一次完成产品的设计与开发。 虽然成本高、周期长，但项目需求问题非常小，后期维护成本低。
敏捷开发：
如您所见，敏捷开发是一种以快速迭代、简单开发为目的的环开发模式。 虽然成本低、周期短，但项目需求问题比较大，后维护成本高。 或者说，敏捷开发一直是一个持续的过程，不存在后维护的说法。
两者的区别：
然后，看看我找到的图。 说明两者的区别。 我觉得是在想象。
瀑布开发是一种传统的开发，在大量的文档集中开发之后，最终会变成一棵大树。 另一方面，敏捷开发会一步步成长为成熟的花。
总之，瀑布开发是在前期花很大的时间进行项目需求的探讨，形成非常标准、专业的文档进行开发。 另一方面，敏捷开发与设计开发并行进行，一边开发一边进行设计。
在
三：产品开发之谈
之前的部分，我们介绍了两种不同的开发模式。 本节介绍产品开发选择什么样的开发模式。 当然，这里的科学不是完全的科学。 要说为什么，那是因为这个世界上不存在完全科学的东西. Orz。在当今的网络世界中，大家都知道，对产品来说最重要的是时间。 过去的话是“一下子恢复呼吸，然后衰退，枯竭”。 我想任何经历过义务教育的人都知道这个根据的意义。 是的，内部无论是研发团队、产品团队还是任何职能团队，时间越长，项目风险就越高。 对外，一个产品长时间不上线是市场快速竞争和资本期的疑问。 所以天下武功唯快不破的秘诀在当今的网络世界是绝对的真理。
因此，当今互联网世界的产品开发中使用了很多敏捷开发的模式，为了解决以前版本的问题，进行了快速的版本迭代。
现在让我们套用一下我看到的话。 “产品的第一个版本将在主要流程通过后立即上线！ ”。
完成
四：版本之谈
敏捷开发后，版本问题注定是不可避免的，因此在产品最初设计时，产品经理需要对每个版本进行初步设计，研究产品节点，传递开发周期。那么，到底怎么计划这个版本呢？
从这里开始是ggdds的愚见。 我们大致可以这样划分版本：
第一个版本：主要过程。 第二个版本
本：优化主要流程。第三个版本：根据运营数据增加功能。当然，你可以不把他看成是第一第二第三版本，而是看成一个顺序，而对于刚开始做的产品，请牢记一句话“不要做太多的功能，你是做什么的，能让用户体验你这个了，就上线”。
五：需求形式之谈
说完了模式，谈完了版本，我们来说说最后的一个话题，到底怎么做PRD需求文档。
当然，今天我们并不讨论需求文档怎么做，那是技术活也是哈姆雷特，每个人写出来都是不一样的。所以没有应该怎么写，写成什么形式，也没有谁写得好，谁写得差。只要是研发团队看得懂的就是好需求。
可是，如果不用说怎么写，那还谈什么需求形式呢？
哈哈哈，我们这里虽然不谈怎么写需求，但是的的确确是要说一下需求的表现形式，接下来我给大家说一下常见的需求形式：
1.文档形式
故名思议，文档形式就是以文档的形式把开发的需求展示出来以供研发团队进行阅读。
Good：
文档形式的需求文档是非常详细的，当然如果水平不行也会出现漏洞，这里我们就忽略水平问题。
文档形式以文字描述项目的各个功能以及开发的流程，对于任何一个研发团队来说都是能够轻松阅读，并且对于项目的验收可以作为很有效的验收工具。
Bad：
坏处就是，太难读了。
我敢保证，现在90%的研发团队成员看见需求文档头都是大的，而且受限于技术水平，在文档上描述的时候会存在理解上的误读。
还有就是，形成文档形式的需求对于项目设计人员来说是需要比较高的要求，也需要很长的时间才能做好的。所以世面上你只听说过“线框仔”而没有听过“打字仔”。
2.原型形式
原型我就不多说了，原型设计的出现是很早的事情了，具体想了解的话去百度吧！原型呢就和我们小时候写的看图写话一样，一张图描述出我们要做什么，简单易懂。
Good：
原型这个东西，效率高，描述准确，理解误差小。而且能很好的直接进行操作，还原设计流程。
而且原型上手快，当然，你要做到很牛逼，那还是很难的。
Bad：
细节上的描述对于原型来说还是差强人意，需要进行非常高保真的原型设计才能完美重现细节设计，这对于原型制作者的要求比较高。 其他坏处我暂时还没有想到，希望大家可以补充，哈哈哈！
注：下面我们就不进行优劣对比了
3.文档+原型形式
这个是什么，我就不说了，你要是这个都不知道话，请你给我打电话！
这种表现形式可以说是当今开发界最完善的开发形式了，不但在可视化上进行了描述，也在文字阅读中进行了描述。对于流程，页面的细节也是很能把握到位，而唯一的缺点就是需要花费的时间比较长。按照现在产品开发的周期来看的话，除非产品经理不吃不睡，才能不耽误开发进度！真的，做过的人才知道。
所以，我们说完了三种展现形式，这个时候选择哪一种就需要产品经理自己考虑了，而推荐几点参考标注：
好了，今天的文章就写到这里。总而言之就是大概的介绍了一下需求这个东西，也没说什么有营养的话，权当看着好玩吧。
如果有什么写得不好的地方，请发送给我邮件督促我改进，谢谢各位看官。
本文系起点学院成都160123期优秀学员 @淡定的星月 (邮箱地址:kame@bsanjia.com) 原创发布，未经作者许可，禁止转载。