摹客
产品
下载
传统意义上，一篇优秀的产品需求文档，往往包含8个重要的元素：项目背景、项目目标、项目方案概述、项目方案详细描述、项目运营方案、项目风险及解决方案、项目时间计划、项目组人员。
产品需求文档之所以有如此丰富的内容，完全是因为在最早期，一直被唯一广泛采用的软件开发模型——瀑布模型。瀑布模型的核心思想是采用结构化的分析与设计方法将产品的逻辑实现与物理实现分开，这就使得我们产品的设计逻辑要足够完善。
并且这个完善，不单单是需求明确，还要细化到每个模块的用例结构，以及每个功能的逻辑流程。
但现在很多公司的软件开发模式都采用敏捷或迭代的开发方式，以求在最短的时间内上线可用的产品版本。尤其是在敏捷开发的过程中，需求有时会在短期内发生多次变化，所以对项目团队的协作也有了更高的要求。在这种情况下，编写传统的PRD文档会拖慢整个产品的开发节奏，也会让整个项目的进度变的难以把控。
所以，当下的产品PRD文档，已经不适合像以往那样，将整个产品的框架都囊括其中。
它的格式必须随着产品开发模式和团队协作方式的变化而变化，变得更加轻量、快速、且拥有完整的变更记录和版本控制能力。
要说到“轻量”，似乎就绕不开一个观点：“画了产品原型，还需要写PRD吗？”
答案绝对是肯定的，因为无论原型的界面多么保真，交互多么还原，它都仅仅只能展示产品逻辑的一部分。就如同上述流程图所示的注册功能一样，其中包含的“检查激活”这个判断，就属于需求分析中无法用原型来展示，却又是功能实现中必不可少的部分。
但其实，在快速的研发节奏和完备的需求分析中，我们是有机会实现完美平衡的。
最为广泛应用的方法是将需求描述写在产品原型页面上，如图中黄色部分就是摹客RP中的便签组件，它能够很好的将该页面内涉及到的功能规则标注在旁侧，帮助设计研发团队能够通过原型对产品有更深的理解。
另外，摹客RP还自带了一个流程图模式，可以直接在原型界面快速进行流程图的绘制。通过这种一边绘制产品原型界面，一边梳理功能流程的方式，能够帮助产品经理反复推敲需求逻辑，避免信息遗漏。
尽管摹客RP已经能够实现全面的原型注释和流程图绘制等功能，但用这种方式来取代需求文档的项目还是非常少，且一般都非常轻量，团队人数不多，沟通从成本较低。
同时，用原型来表述需求，还有个最大的问题，就是很难用可追溯的方式去记录需求变更以及开发迭代。并且当开发团队足够大，项目功能足够多的时候，也会出现非常困难的需求管理问题。
所以，产品需求文档在更多时候，是不可以被替代的。
但并非选择了产品需求文档就等同于选择了冗长的文字描述，因为同样，我们也可以使用摹客的文档功能，直接在PRD文档中引用产品原型，或产品流程图，快速的简化产品需求文档中相关的文字描述。同时也避免了我们平时编辑需求文档时，因为无法实现流程图在文档中的同步展示，而需要反复修改、粘贴的过程。
而除了梳理功能和逻辑以外，产品需求文档的另一个用处却常常被大家所遗忘，那就是留档备查。
在整个项目研发过程中，需求文档常常需要经过多次修改，这种需求的更迭需要用更高效便捷的方式来进行管理。
一般来说，需求文档修改记录一般包含版本号、修改内容、修改人、修改时间这四大部分。而我们可以看到，用摹客管理需求文档，可以很便捷的对版本变更进行有效的管理。他能自动保存我们需求文档的更新版本，并同步记录下时间和修改人，让需求文档的变更记录更加简单高效。
梳理好逻辑、表达出需求、记录好变更、管理好版本，才是PRD的本质。
只有明确了需求文档呈现的方式，才能将他的价值最大化的发挥出来。
摹客协作
摹客RP
摹客DT
摹客超级版