后台管理系统PRD该怎么写？

近段时间独立完成一份运营管理平台的PRD，借此分享一份在下的心得体会。在此之前仅写过完整的C端产品PRD，因此也参考了大量与B端产品需求相关的文章。惭愧，因为并没有找到合适的用于B端的PRD模板，所以参考各位大佬的见解，自己总结了一套方法。

不能参照C端的PRD来写吗？

原则上来讲是行不通的，C端产品和B端产品所面向的用户及功能业务少有共同点。C端产品侧重如何满足用户的衣食住行需求，针对个体用户；而B端产品更加贴合企业实际，侧重提升客户的生产和办公效率，降低生产成本，针对企业或组织。侧重方向的差异，也就导致了PRD的差异。

一、为什么要写PRD？

这个问题得先唠叨一下，因为刚入行时因为某些原因并不是很重视这个问题，只知道是产品经理必备技能之一，但是鲜有机会去实际操作，也难以领会其深意。对于想在产品这条路上砥砺前行的人来说，这是不容忽视的一个重点。

PRD（产品需求文档）从需求到功能的具体实现，包含各项业务解决方案及相关数据项，是所有开发及测试人员在产品开发过程中的必备文档。一份完整的、详尽的PRD，在下认为主要作用有以下几点：

减少产品与研发之间的沟通成本；

增强产品的容错率，确保产品的准确性；

帮助产品经理梳理思路、流程及细节；

作为后期对产品验收的凭据之一。

每个产品都需要一份完整的、详尽的PRD吗？也不尽然。对于某些复杂度不高，产品研发团队默契度高，或者不易产生歧义的产品来说，如果没有特殊的用途，PRD尽量简洁，提升文档的可阅读性，反而更有利于产品的研发效率。

如果没有PRD，所有细节可能都需要产品与研发保持密切沟通，按时总结盘错。避免研发人员研发时遇到不明了的地方添加过多自己的想法，否则最终的产品做成什么模样真得看天意了~~

二、后台管理系统PRD应该包含哪些内容？

1）版本修订记录。主要包含版本号、修订人、修订日期、修订描述等。它在产品出现问题，追根溯源时可以起到巨大作用。（新人注意：版本修订不是在原版本上修改，每个版本修订完成后都需要单独保存）

2）简介。这里的简介不是仅仅对产品的简介，可以是对文档的简介、产品泛义上的介绍（背景、目的、产品适用范围、目标用户详情）等。阅读后能够对整个产品有大概印象。可视情况添加预期收益、竞品情况、名词解释等内容。

3）产品概述。这里的概述跟上述的简介有所不同，主要是对于产品各功能模块的概述。包含功能概述、产品总体流程、功能摘要等。其中，功能概述是在功能层面上的一个概述，不需要写太多；产品总体流程是各功能模块之间的联系，通过流程图或者思维导图体现出来，尽可能清晰详细；功能摘要是对各模块的摘要描述。阅读产品概述后对整个产品具有的功能及各功能能做到什么有大致印象。

4）策略介绍。不同于C端产品重视用户视觉体验及交互体验。后台管理系统更重视数据管理、各项分类，尽可能简化客户操作，以到达提升效率、减少成本的终极目标。针对某项业务或者某类需求场景，怎么做能够实现并且清晰易懂好操作，这便是策略需要解决的问题了。

5）前端页面功能详情。使用者是直接通过前端页面操作的，内部逻辑及业务这里可能看不出来，但是这里看到的是最直观的产品。每一个模块有哪些页面，每个页面有哪些功能，功能点有哪些交互，哪里与上述策略有关联都可详细描述。要求具备原型制作基本能力，有较好的交互设计，图文搭配可以更直观的表达各功能详情。

6）其他产品需求。这部分根据产品实际情况进行增删，可能包含性能需求、数据监控需求、兼容性需求等。都是业务需求之外的关于系统本身的需求，直接影响产品的第一使用感受，研发团队默契度不高的话最好做详细描述。

7）风险分析。在下认为，对于一个看文档的人来讲，如果对产品本身功能都没有太多了解，看风险分析也没有多大用处。此处的风险分析仅作为整个产品从研发到发布这个阶段可能遇到的风险作出分析，不需要太过复杂。包含风险内容、可能性、严重性、应对策略、可应对性等信息即可。

8）其他。对于撰写本文档相关的文档、附件、项目排期、测试用例等信息，可根据实际需要增删。

三、策略介绍怎么写？

策略介绍是整个文档中最重要的一部分。每一个策略介绍需要从问题描述到最终如何解决形成一个逻辑闭环。先从各视角（应用场景、技术、逻辑）做一个详细介绍，明确策略重点及需要解决的问题；再对策略制定及制定原因做详细描述，为了方便解读，可配上流程图或思维导图辅助说明；最后加以小结，确认有无漏洞。

四、前端页面功能详情怎么写？

前端页面功能详情在文档中的重要性仅次于策略介绍。可以通过模块与页面的层级关系作为标题的关系，务必包含系统主要功能模块，通常来说，这部分是最容易造成文档完整性不足的地方了。

就单个页面的说明而言，在下更喜欢做成表格的形式，层次分明。主体包含前置条件、优先级、需求详细描述、后置条件，可视情况添加应用场景、功能摘要、补充说明。其中，需求详细描述可以配合原型设计做详细解读，更容易理解。

五、如何提升文档的可阅读性？

1）前后描述一致。就上述内容而言，功能摘要、策略、前端页面功能详情必然会存在关联的情况。务必确保各部分的内容描述一致，不出现偏差，不能给研发曲解的机会。

2）层次分明，图文并茂。对不同性质的内容，比如查询输入、操作按钮、数据列表做明确区域划分，一看描述就知道在哪里找对应的原型图。又比如管理系统中的功能结构、账户管理、角色管理等，正确的划分层次，图文配合说明，均能获取不错的效果。

3）抓重点、重细节。用简介的抓语言抓住重点可以保证重要内容不会缺失，并且容易领会要表达的核心意思；重细节可以避免不必要的弯路，影响整体研发效率。能用一句话说清楚的不再多加说明，能用一个例子讲清楚的不再反复强调，能用一个词表达的不用句子来叙述。

结语：本篇内容主要是在下的心得体会，并没有刻意的加入图文及样例（太费时间了/wo bi jiao lan），以此勉励自身继续努力学习。也希望对各位看官有所帮助。