![]()
一、需求文档的重要性
产品经理输出的需求文档在整个产品开发过程中起着至关重要的作用。首先，明确产品需求，避免遗漏。一个项目往往包含众多需求，将这些需求记录在文档中并梳理清楚逻辑，能够有效避免需求的遗漏，同时也方便对需求进行管理。据统计，在没有规范需求文档的项目中，需求遗漏的概率可能高达 30%，而有详细需求文档的项目，这个概率可以降低到 5% 以下。其次，方便其他人员查阅，降低团队成员的沟通成本。当团队其他成员需要了解项目需求时，直接阅读需求文档即可，无需反复询问产品经理。这在产品经理离职时的工作交接中也尤为重要。例如，在一些大型项目中，如果没有需求文档，新接手的人员可能需要花费数周甚至数月的时间去梳理业务和产品逻辑，而有了规范的需求文档，这个时间可以缩短到几天。最后，信息存档，作为功能开发的依据。如果开发出的功能不合预期，需求文档可以作为依据，避免相关人员之间相互推诿责任。例如，当出现功能与需求不符的情况时，通过查阅需求文档，可以明确是哪个环节出现了问题，从而快速解决问题。总之，需求文档对于产品经理和整个产品开发团队来说都是不可或缺的重要工具。二、需求文档的结构与呈现方式
（一）文档结构规划
需求文档的结构应清晰合理，各个部分之间相互关联，共同构成一个完整的需求描述体系。需求变更日志和版本迭代记录作为文档的开篇部分，记录了需求从提出到最终实现过程中的每一次变化，为后续的开发和维护提供了重要的参考依据。通过软件导航窗格预览，可以快速定位到不同的部分，方便查阅。背景方案价值部分则深入阐述了需求产生的背景、解决方案以及实现该需求所带来的价值。这部分内容有助于团队成员更好地理解需求的重要性和必要性，从而提高工作的积极性和主动性。名词解释部分对于文档中的专业术语进行了明确的定义，避免了因术语理解不一致而导致的沟通障碍。流程图部分则通过直观的图形展示了需求的业务流程和逻辑关系，使团队成员能够更加清晰地了解需求的实现过程。这些内容相互配合，共同构成了一个完整的需求文档结构，为产品的开发和实现提供了有力的支持。（二）呈现方式选择
Axure 一体化需求文档和 Word 版需求文档各有其特点和适用场景。Axure 一体化需求文档具有方便查看、原型与文档说明相结合的优势，能够让团队成员在查看原型的同时了解需求的详细描述。然而，可能会给人一种不太 “严肃” 的感觉。Word 版需求文档则容易留存，比较正规，以文字为主，适合对需求进行详细的描述和分析。对于大项目，建议统一使用 Axure 写需求。因为大项目通常涉及多个功能模块和复杂的业务流程，Axure 能够更好地展示原型和业务流程，方便团队成员理解和沟通。同时，Axure 还可以通过添加链接和交互效果，提高文档的可读性和易用性。例如，在一个电商平台的开发项目中，如果使用 Axure 一体化需求文档，可以将各个页面的原型和功能描述整合在一起，通过链接和交互效果展示页面之间的跳转关系和业务流程。团队成员可以直观地了解整个平台的功能和业务逻辑，提高开发效率。而如果使用 Word 版需求文档，则需要通过大量的文字描述和截图来展示需求，可能会导致文档篇幅过长，不易阅读和理解。三、需求文档的具体内容
（一）需求变更与版本迭代
需求变更在产品开发过程中是不可避免的，因此详细记录变更原因、前后变化及影响至关重要。例如，由于市场需求变化，原本计划开发的功能 A 调整为功能 B，这可能是因为市场竞争加剧，需要更快地推出更具竞争力的产品。记录变更原因可以帮助团队成员理解决策背后的逻辑，避免类似的变更在未来重复发生。同时，展示产品经理的思考路径和功能版本的迭代过程，可以让团队成员了解产品的发展历程，便于复盘和交接。比如，在某个版本中，产品经理考虑到用户反馈和数据分析，对功能 C 进行了优化，这一过程可以作为宝贵的经验教训，为未来的产品开发提供参考。（二）背景方案价值
说明需求背景时，需要涵盖产品行业现状、资源技术限制等方面。例如，在金融科技行业，产品需要满足严格的监管要求，同时要考虑到数据安全和用户隐私。了解行业现状可以帮助产品经理更好地把握市场趋势，为产品的定位和发展提供指导。资源技术限制也是不可忽视的因素，比如开发团队的人力、时间和技术能力等。在资源有限的情况下，产品经理需要找到最佳的实现方案，平衡需求和资源之间的关系。
按照用户场景问题方案框架，提炼一句话方案，能够让团队成员快速理解需求的核心内容。例如，“针对年轻上班族，在上下班高峰期提供快速、便捷的出行解决方案”。考虑资源限制可能有折中方案，这意味着在实际开发过程中，可能需要根据资源情况对方案进行调整。比如，在开发初期，由于资源有限，可以先推出一个简化版的功能，然后逐步完善。
明确需求实现的用户价值和业务价值。用户价值可以是提升用户体验，例如提供更加个性化的服务、优化界面设计等。业务价值则可以是提升业务收入、增加用户留存率等。例如，通过推出新功能，吸引更多用户注册和使用产品，从而提高业务收入。同时，也可以通过优化用户体验，提高用户留存率，为企业带来长期的价值。（三）名词解释
对专业名词进行解释并加示例说明，可以有效避免团队成员在理解文档内容时产生歧义。比如，在电商行业中，“SKU” 是一个常见的专业名词，它代表库存保有单位。通过解释这个名词，并给出具体的示例，如 “一款手机有不同的颜色和存储容量，每种组合就是一个 SKU”，可以让团队成员更好地理解文档中的相关内容。（四）流程图绘制
流程图可以分为整体流程图、模块流程图和功能流程图。在跨角色、系统、模块及多判断逻辑时绘制流程图，可以帮助团队成员更好地理解业务流程和功能逻辑。例如，在一个电商平台的订单处理流程中，涉及到用户、商家、物流等多个角色，以及订单生成、支付、发货、收货等多个环节，通过绘制整体流程图，可以清晰地展示整个业务流程的全貌。同时，可以根据实际情况选择不同类型的流程图，如业务流程图、数据流程图、泳道图等。业务流程图主要展示业务流程的发生过程，数据流程图则重点关注数据的流向和处理过程，泳道图则可以清晰地展示不同角色在业务流程中的职责和协作关系。（五）其他要点
记录需求文档的修改内容、原因、人员和日期，可以方便团队成员查看和同步。例如，在某个版本中，由于需求变更，对功能 D 的描述进行了修改。记录修改内容可以让团队成员了解具体的变化，原因可以帮助理解决策背后的逻辑，人员和日期则可以明确责任和时间节点。
介绍项目或需求的背景，包括现状、问题、结果、动作、目的、收益和价值。例如，在一个医疗健康产品的开发项目中，现状可能是市场上缺乏一款针对特定疾病的管理工具，问题是患者难以有效地管理自己的疾病，结果是患者的治疗效果不佳。动作可以是开发一款医疗健康产品，目的是帮助患者更好地管理疾病，收益可以是提高患者的治疗效果和生活质量，价值可以是为社会带来健康福祉。
涵盖查询性能、并发要求、风控要求等方面内容。例如，在一个金融交易系统中，查询性能要求高，需要在短时间内返回大量的数据；并发要求也很高，需要能够同时处理大量的交易请求；风控要求严格，需要对交易进行实时监控和风险评估。
可写产品规划及需求变更记录，有助于技术提前考虑数据库设计。例如，在产品规划中，预计未来会增加新的功能模块，这就需要技术人员在设计数据库时预留一定的扩展空间，以便在未来能够快速地实现新功能。同时，记录需求变更也可以让技术人员及时调整数据库设计，避免因需求变更而导致的数据库重构。四、不同类型需求文档的区别
（一）BRD、MRD 和 PRD 的区别
- 定义：BRD 是基于商业目标或价值所描述的产品需求内容文档。它主要用于在产品投入研发之前，为企业高层提供决策评估的依据。
- 解决问题：BRD 主要解决 “哪里能赚钱？怎么赚到这个钱？可以赚多少钱？” 的问题。
- 核心用途：BRD 分析内容主要围绕商业可行性，一般包含产品介绍（产品定位、目标用户等）、商业模式、盈利模式、所需资源、产品规划、竞争对手等维度。其核心用途是为企业高层提供决策依据，争取更多资源。例如，在一个新的电商项目中，BRD 会详细分析市场规模、竞争对手、盈利模式等，以确定该项目是否值得投入资源。
- 作用：MRD 在产品项目中起到 “承上启下” 的作用，是产品项目由 “准备” 阶段进入到 “实施” 阶段的第一文档。它对规划中的产品进行市场层面的说明，为后续工作提供方向指导。
- 解决问题：MRD 主要解决 “赚谁的钱？凭什么赚钱？好不好赚钱？” 的问题。
- 文档呈现结果：MRD 主要包括产品介绍、目标市场分析（市场现状、趋势、问题机会等）、目标用户分析（用户特征、细分场景、具体需求等）、竞品分析（产品分析、用户分析、市场分析等）、产品需求概况（产品定位、产品核心目标、产品结构、产品路线图、产品功能性需求、非功能型需求）等内容。例如，在一个社交产品项目中，MRD 会详细分析目标用户群体、市场竞争情况、产品功能需求等，为产品的实施提供具体指导。
- 定义：PRD 是将商业需求文档 BRD 和市场需求文档 MRD 用更加专业语言进行描述。
- 解决问题：PRD 主要解决 “用什么赚钱？怎么多赚钱（产品设计、产品安全）。” 的问题。
- 文档呈现结果：PRD 一般包括版本介绍、版本修改记录、共性规则、业务流程、产品结构、原型和说明、非功能性需求（如数据需求、性能需求、适配需求等）等内容。例如，在一个移动应用开发项目中，PRD 会详细描述产品的功能需求、界面设计、性能要求等，为开发人员提供具体的开发指导。
（二）各文档关系
从流程上看，先有 BRD，决策是否要开始一个产品。BRD 从战略高度告诉我们做什么产品，它就像一个项目的蓝图，为后续的工作提供了方向。例如，一个新的互联网创业项目，首先需要通过 BRD 来论证项目的商业可行性，确定项目的目标用户、商业模式、盈利模式等。接着是 MRD，决策如何开始一个产品（when，how）。MRD 从战术的角度告诉我们怎么做，它在 BRD 的基础上，进一步分析市场情况、目标用户需求、竞品情况等，为产品的实施提供具体的策略和方法。例如，在确定了一个电商项目后，通过 MRD 来分析市场规模、用户需求、竞争对手等，确定产品的定位、功能需求等。最后是 PRD，决定要开始的产品具体是什么样的（what）。PRD 是前两者具体的落地实现方案，所有的 PRD 都是为了实现前面的公司规划和愿景。它详细描述了产品的功能需求、界面设计、性能要求等，为开发人员提供具体的开发指导。例如，在确定了电商项目的定位和功能需求后，通过 PRD 来详细描述产品的各个功能模块、界面设计、数据需求等，为开发人员提供具体的开发指导。从逻辑上看，BRD 比较笼统地提出我们要做某件事，并说明做这件事的好处，相当于抛出一个论题。MRD 相当于用论点支持我们的论题，具体论述我们该通过什么样的方式达到我们的商业目的，在一系列分析后，拿出可行性方案，输出指导性文档。PRD 则是具体的论据，如何具体实施产品方案。这三个文档相互关联，共同构成了一个完整的产品需求体系。五、需求文档的撰写技巧与注意事项
（一）技巧提升
- 颜色对比、大小差异、形状区分、符号标记等优化文档可读性
在撰写需求文档时，可以运用颜色对比来突出重点内容。例如，用红色字体标记重要的需求变更内容，蓝色字体表示可跳转的链接或交互说明。通过颜色深浅、色域对比，能让读者一眼抓住文档重点。同时，遵循一定的 UI 设计规范，合理运用字体大小差异。如 22px 用于页面标题、17px 用于列表标题、14px 一般是列表描述文字，使文档层次分明，提升可读性。此外，形状区分也能进一步降低文档的阅读难度。像流程图绘制时，用圆角矩形代表起始节点、矩形代表流程动作、菱形代表条件判断，让复杂的流程更加直观易懂。符号标记则可以通过一些特殊符号，如中英文间隔、“”「」等，突出重要内容的层次，加深文档读者的印象。- 图表呈现、维度提炼、概念封装、领域知识提升文档专业性
一图胜千言，能用图表呈现的内容尽量用图表。比如，对于复杂的知识概念，可能需要几百字才能阐述清楚，而通过图片、表格进行呈现，读者几分钟就可能完全明白。例如，用 UML 画简单的状态图来定义复杂的订单状态，清晰直观。维度提炼是将未经优化加工的内容进行总结提炼，找出差异和共性，抽象出维度属性，然后按维度进行整理归纳、分门别类。比如，脱不花老师在《沟通的方法》中分享的职场倾听方法，把沟通中的话题提炼成情绪、事实和期待三个维度。概念封装是用一个简单的概念表示一系列关联度较高、重复使用的复杂内容，提升内容的复用率。例如，在需求文档模板中，常用的全局说明、名词解释、公式复用、参数说明、公共组件、交互解耦等文档模块就是概念封装的应用场景。领域知识则要求根据不同的读者对象，针对性地呈现专业内容。面对公司老板，要在一两分钟内让其快速 Get 到文档重点，内容侧重于简洁，用大白话讲清楚核心概念；面对业务方，既要表达得简单易懂，又要呈现专业的业务知识，快速达成共识；面对前后端团队，要基于开发视角和技术知识撰写文档，包括数据处理、异常分支等复杂的规则交互，可通过类似 UML 的统一建模语言，画状态图、流程图来呈现需求，既专业又高效。- 通过核心逻辑与原型结合，提高需求评审效率，减少开发卡点
需求文档应注重核心逻辑与原型的结合。在需求评审会议上，先讲核心逻辑，让参会人员清晰了解整个需求的逻辑。人的精神容易分散，先讲核心逻辑能在会议最前面把最重要的内容讲清楚，使大家在看原型时更好地理解。原型是核心逻辑的具象，包含众多细节，在原型中要尽可能描述清晰需求，不遗漏需求，考虑缜密。这不仅体现产品经理的逻辑能力，还能减少开发过程中的卡点，如因考虑不周全而导致开发不顺畅或者延期等情况。例如，在一个项目中，产品经理通过图文结合的方式，将核心逻辑表达清楚，同时附上详细的原型链接，使开发团队能够快速理解需求，提高开发效率。（二）注意要点
需求文档的结构应清晰合理，让读者能够快速了解文档的思路和内容。可以先规划好整体的文档结构，再开始写具体内容。例如，对于 B 端产品的文档，可能涉及安全性、与其他系统的数据交互规则、数据的存储备份规则等非功能性描述。没有标准的文档结构，具体要根据项目情况而定，只要能把需求明确清晰地表达出来即可。同时，建议打开 word 或 WPS 中的导航窗格，方便预览文档的整体结构，也方便快速查看某个模块的内容。- 注意可读性，分点描述、表格展示、突出重点、加题注等
为了提高文档的可读性，在大段文字描述时，可以分点描述，以有序列表或无序列表的形式呈现内容，同时注意分段。尽量以表格的形式展现内容，比如描述同一个事件的多种状态时，表格比大段文字更合适。对于需要重点强调的内容，可以给字体标上显眼的颜色，让读者一眼就能注意到。文档里的配图和表格要加上题注，让读者知道图或表主要想表达什么内容，减少读者的认知成本。此外，文字的行间距、段落的段间距也会影响文档的视觉效果，要根据正文字体大小进行调整，看起来顺眼即可。- 对产品描述完整，吃透产品、全方位思考、多体验产品以罗列齐全规则
对产品描述的完整性至关重要。要尽可能把一个产品的功能规则全部描述出来，比如短信验证码的相关规则包括多久能获取一次验证码、某段时间内最多可以获取多少次验证码、验证码有多少位数、有效期是多久等等。为做到这一点，可以从三个方面着手。首先，写文档前要把产品吃透，了解开发产品的目的、功能和相关规则，各个功能模块间的关系以及需要特别注意的点，同时要能熟练使用产品。其次，培养全方位思考问题的意识，主动思考一件事情发生前、发生时、发生后的规则分别是什么，是否有前置条件或特殊条件，如果某个条件不满足会怎么样等。平时可以有意识地训练自己，养成这种思考问题的习惯。最后，多体验各种产品，研究它们的功能约束规则和设计原因，比如淘宝的搜索框设计规则。可以对各种情况进行尝试，探究其对输入信息的校验，也可以多看别人写的需求文档，学习其中对规则的约束性描述。—END—
更多产品经理干货知识
可以订阅kK最新整理的
2024【全栈产品经理知识库】👇👇
—— 目录大纲 ——
![]()
![]()
![]()
最后再说几句：
kK在产品岗设计工作10余年，见证了PC时代到移动互联网的变迁、O2O的崛起和平定、疫情前后经济剧变，以及近期AI颠覆式进化，每一次时代的变革，是机遇也是挑战。
💪💪产品的路很孤独，kK陪你一起打怪升级~
产品经理知识库，是kK产品岗工作10余年以来，反复整理和累积沉淀的产品知识学习体系
完全可满足和适合互联网全业务领域产品的朋友入门与进阶，比如有转岗意愿、有求职计划、以及正在求职过程中的产品经理 (包括C端产品经理、saas产品经理、电商产品经理、中台产品经理、策略产品经理、金融产品经理、教育产品经理、政务产品经理等产品方向)。
还有也适合其他互联网岗位 0基础想转行或进阶的同学（如：运营、UI/UE、开发）等岗位转型。
👉人与人之间的差别是认知差，要懂得：花最低的成本，用最快的时间，实现弯道超车。
👉有时候打开思维认知，很有可能只是大神的一篇文章、前辈的一句话、甚至一个字，kK踩坑10余年，深有感受。
👉一顿饭钱换一个学习的机会，打开认知，可乐而不为！
同学们订阅后，记得添加kK企业微信号，开通网盘权限 获取资料
![]()
