本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
产品需求文档
产品需求文档(Product Requirement Document，PRD)的英文简称。是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
为什么开发需要需求文档
需求文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。
- 稍微大一点的团队产品经理未必能向每个人传达产品需求，这就需要有一个文档的形式来向项目的所有成员来传达需求，这就是文档的来源。
- 由于产品经理经常会变更需求，经常爱拍脑袋，容易变卦，所以程序员就想到用一个文档来约束产品经理。
- 测试人员需要根据产品需求文档来验收产品质量。
- 当你的项目有新人进入的时候，可以让新人更快的了解产品。当你离职的时候，继任的产品经理也可以根据你的文档来熟悉产品迭代的内容。
因此，需求文档的编写变成了团队传递信息的必要文档。
什么是敏捷开发
埃德蒙·伯克说过[我们担心人们会依照自身的理性主导起生活和交易，因为我们怀疑每个人的理性是相当有限的。]
应用到产品经理身上，我们可以把它翻译为：[我们担心产品经理们会依照自身对用户和社会的理解，来固执的设计产品，因为我们怀疑每个产品经理对用户的理解都是相当有限的。]
这就是敏捷开发的起源，那么我们该如何做到敏捷开发呢？
快速迭代
产品通过短周期的迭代交付，通过不断的迭代完善产品。
快速尝试
避免长时间的需求分析和用户调研，快速进行尝试。快速验证市场和需求的真伪，抢占市场。
快速改进
在地带周期过后根据客户反馈快速改进。因为产品迭代很快，肯定会有不完善的情况，产品上线后需要收集用户需求，方向错了就调整方向，有bug就快速改bug。
充分交流
团队成员的无缝交流，如每天短时间的站立会议。交流尽量扁平化，团队成员可以在坐的近一些，这样交流起来比较方便，而不是像大公司一样，一件事情需要走很多流程。
简化流程
拒绝一切形式化的东西，使用简单易用的东西开始工作。例如;把冗长的word文档去掉，代指在原型上简单的标注，其实说实话，你写的很长篇幅的PRD文档，开发的兄弟妹妹也不一定会看，白白浪费写文档的时间。
敏捷开发产品需求文档该怎么写
既要敏捷开发，又要保证开发质量，这个时候PRD(产品需求)文档就显得重要了。
做好版本控制
版本历史记录要有。你的原型可能会更新好几次，这个时候你需要做好版本控制。每次更新的时候在版本命名上显示是那个几点几版本。同时在版本控制上显示每一版本更新了那些内容，这样别人一看就会一目了然。
功能列表要有
功能列表告诉项目成员我们这一版本迭代那些内容，前台需要做那些，后台需要做那些，这样开发即使没有文档，也可以根据功能列表来，而不会有遗漏，测试也可以根据你的功能列表。功能列表可能会更新，每一次更新可以用不同颜色的文字给表示出来。
功能说明要直接在原型图上标注
开发者一般都是看着原型开发，你之前写的冗长的产品需求文档根本不看的。那么遵循敏捷开发的“尽量减少文档原则”，可以直接讲功能说明和需要注意的东西标注在文档上面，对于减少PM和PD的工作量都很有帮助，当然前提是你的产品需求完整且逻辑清晰。
产品全局结构图以及一些重要的流程图不能省略
首先，全局结构图。产品全局结构图相当于房子的骨架，相当于文章的目录，别人看过你的全局结构图就知道你的产品大概分成那几个部分，这样别人阅读接下来的原型设计和文档的时候就会思路清晰。
其次，一些重要的功能流程图需要写。一些基本的流程图可以不写，但是一些重要的功能流程图。这样项目成员在会议以后也可以通过文档来重新温习一下。同时你把流程图整理好，也有助于开发人员的开发思路的建立，大大提升开发速度。
需要把规则和异常情况写上去
很多时候产品经理开需求评审会挨批的原因就是没有考虑周全，只考虑正常的流程，而没有考虑异常流程情况，无网络的情况等。例如：网贷平台用户支付系统你只想到用户输入支付密码，完成购买。但你没想到新用户用户如果没有实名认证是不是先要实名认证，认证完成以后要不要设置交易密码，如果交易密码输入错误怎么办？是提示他忘记密码还是让它重新输入？同时交易密码错误次数需不需要进行限制？如果支付金额不足怎么半…等等。这些只有考虑的细，考虑的全面。开会的时候才能少被喷，才能有气场。同时你考虑全面了，开发人员也会节省时间，不会在做的过程中给你发个邮件说出现某某情况怎么办。只有让他们信服你，减少他们的工作量，你和他们沟通起来，才会顺畅。
重要的名词需要清晰简洁的定义
重复出现的名字就不需要解释了。例如用户，当然如果你的目标用户变更了就需要重新解释一下，当然解释的词语的原则就是第一次出现而且比较重要，同时尽量用简洁精炼的语言把名词解释出来。
总结：其实实现敏捷开发文档只是一个手段，更重要的是多沟通，减少因为沟通少而产生的误解。当然一个好的PRD文档可以增加你们的沟通效率。
版权声明：本文为博主原创文章，未经博主允许不得转载。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 编写敏捷开发的产品需求文档教程