文章开头：本文是阿基米德V老师发表在产品壹佰的文章（http://www.chanpin100.com/article/105182）转载文章仅供大家习，不作任何商业用途。
原来啊，过去自己认为的好文档，和技术眼中的好文档，有着天差地别。
最近，就“一篇好的需求文档是什么样的”这个问题，我和研发大哥讨论了很长时间。发现过去自己认为的“好文档”，和技术眼中的”好文档“，有着天差地别！
为此，写总结一篇，整理了需求文档写作中的一些注意事项。
一、写作前需要思考的问题
1、问题&起因
为什么要做这个需求？遇到了什么问题？
2、可量化目标
做完这个需求，你想要达到什么样的结果？从“PV增长5%”到“转化率提高3%”，你需要一个明确的目标来衡量自己的产出价值。
3、需求背景
你该如何向同事、不相干的人去解释这个需求？如何让别人听明白你在做什么？
4、方案详情
需求从发起到落地，需要切实可行的方案来保证它一步步推进。而其中的每一步都会受到别人的质疑。因此，需要尽可能想到每一个细小的逻辑分支。
5、时间轴（Roadmap）
关键的时间节点包括：确认交互、视觉定稿、需求评审、进入开发、联调测试，以及上线日期（非常重要）。
二、开始着手PRD写作
1、快速完成一个草稿（1-2 个小时）
先把脑海中所有想到的细节都列出来，用通俗易懂的语言列出一个清单——给自己看，这样便于整理之后的思路。
2、和相关人员分别进行一对一讨论 （1-4 个小时）
这个步骤的目的是过一遍文档中的细节，优化你的方案。
干系人包括：需求owner、交互视觉负责人、研发、其他相关的人。
从不同岗位的视角来看，你的方案够合理吗？在这个环节，你会受到很多异议，把它们都记录下来，因为这些很有可能成为研发时的大坑。
3、撰写和编辑文档 （0.5-3 天）
将上一环节确定的细节一一梳理，添加到文档的相应位置。同时，需要不断优化文档的结构，以确保研发团队能看得下去。
4、群发文档 & 安排需求评审会（15 分钟）
将文档群发给项目的所有利益相关方，并且抄送给其他可能对文档感兴趣的团队（例如你所在的产品团队，整个支持团队等）。
跟进这些关键人员是否接受了会议邀请：将会执行这件事情的人，和所有对这件事情有通过/否决权力的人。
5、需求评审（1小时）
在开始会议之前必须做的一件事：确保所有人都看过了你的文档。如果没有，先花一两分钟让大家把文档浏览一遍。
在评审时，你需要尽可能让所有人都知道，你想要做一件什么样的事，为什么要做它，能给整个团队带来怎样的利益。
在方案阐述完成后，给研发充足的时间来思考可能存在的问题，并一一记录下来。
6、通过评审后，及时建立工作群组和工单 （1-2 小时）
在工单上附上PRD的链接，同时，在建立工单时就敲定项目排期。如果可以，把排期&责任人放在PRD首页，让研发每次进入文档都看到它。
三、Tips：如何写出研发爱看的PRD文档？
1、简洁，再简洁
冗长的下场就是研发人员根本不想打开你的PRD。因此，为了确保他们有动力读完，尽量使用简洁的语言，不说废话。
2、在图表上下功夫
流程图、线框图、各类交互和视觉效果图，这些能让人更好地理解需求。
3、和研发一起完成PRD
从开始动笔到最终定稿，尽量多地和研发讨论方案细节，以确保技术可能性和实现方式。这样研发也会有参与感，积极性也会更高。
文章结尾：再次申明所有转载文章仅供学习，感谢阿基米德V老师的分享，如果喜欢我的文章点关注❤️吧！比心呦！
