产品需求文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，如果你已经能可以撰写需求文档，那么你现在需要看看本文，在会撰写的基础上能够将产品需求文档撰写的更深入。
一、简述
撰写结构与开发思维，是在产品需求文档基础上，需进一步提升的核心基本功。而这个基本功，决定着能否输出高度模块化的产品需求文档。
但是，许多的新入行的产品新人，对产品需求文档认识，局限在：“套个模板、添加个前置、后置条件、流程图”等认知，便能输出一份严谨的产品需求文档。事实上，这些都只是些浮于表层的事物！对于模板“是否拥有前置条件、后置条件”这些模块结构，对于产生优质的产品需求文档，其实并不是核心的决定因素。
纠结于产品模板，会导致新人误入形式，远离本质。这种场景下，很难将产品需求文档撰写严谨，最终必然导致内容空泛。我们对产品需求文档最终达到的效果，进行TAG概括：
推理严谨
逻辑合理
描述细致
场景清晰
在进阶版篇章中，我们从产品需求文档模板的框架中跳出来，在高一层的维度中，从“方法论”的角度展示。
根据案例：产品需求文档A与产品需求文档B，基于撰写结构与开发思维，如何实现“严谨、合理、细致、清晰”效果，进行案例分析。
二、撰写结构
撰写结构，就是基于被撰写的产品功能模块，有规划的进行内容组织。且将组织的内容清晰的描述出来，而内容组织并不局限在使用某个产品需求文档的模板中，只需要拥有个人“方法”，将产品功能描绘清晰即可。但，它须坚持一些原则：
符合浏览对象浏览信息流的习惯，被组织的内容权重主次清晰，并起到引导作用。
内容组织紧凑，功能模块内容结构划分清晰，区分明显。
结构化的撰写方式，以结构化的形式展示数据流、业务流、页面布局逻辑。
严谨的是与否判断。
产品需求文档A，在描绘需求时，采用的是“功能名称-需求说明（内容描述）-原型图”形式作为撰写结构，进行文档撰写，描述不够深入导致整体较为空洞，体现在：
页面布局：缺乏1、2级层级关系，用户浏览信息时，缺乏主次。需要查看参与者个人进行信息区分，队内容层级筛选。
整体排序：排序不符合查看参与浏览信息方式，不能起到引导用户有节奏地进行产品功能内容传递。
模块结构：内容结构单一，在“需求说明”上，无法系统化地进行产品功能细节描写，页面的数据流、逻辑关系无法清晰的表达。
撰写结构：文档描述口语化严重，缺乏结构化语言，思维零碎，无法引导查看参与者思维进行文档价值传递。
基于上述原因，产品需求文档A，对于产品功能涉及的“字段、操作逻辑、数据流、排序规则….等，都无清晰的表达出来。
采用竖并列式的结构进行文档撰写，整体显的紧凑，内容丰富，主要体现在：
完整的文档模块
产品需求文档B，文档模块，围绕产品功能的数据流与逻辑关系展开搭建，框架模块较为清晰。从产品功能名称介入，从“用例图、前置条件、后置条件、功能概述”的角度，将产品功能大的框架明确。
产品框架的基础上，进行产品功能模块细化，绘制出：“字段列表、表单、操作、交互、算法模型….”，而描述的模块与结构化的思维，将产品功能主次区分开，将细节进一步深入描述。如进行产品功能规划：“从主业务流切入，将核心流程打通。”后台：逻辑业务流，前台：选购支付流（流程不通，转化率必然很低）。
规范的内容排序
严谨的功能模块，结合内容主次排序，如何符合参与角色浏览文档的习惯，便显的非常重要。产品需求文档A，在文档排序上，使用：“功能名称-功能说明-原型图”，这种描述逻辑是：
查看参与者，需要先看需求说明，才进入查看原型图，这种查看文档的交互方式，是有问题。
对 于文档传递信息而言，第一步是进行整体的产品功能概念的价值灌输，从原型图了解大体的逻辑与数据，让参与对象可以在功能上对整体模块进行了解。在这个基础 上，才进入细节描述，这个过程中才结合原型图，逐渐将功能细节撰写排序。这样利于后续交接方与提出方、研发方，在查看文档时，最短的时间熟悉产品功能的大 体逻辑。
而产品需求文档B，在内容排序上，采用“功能名称-原型图-整体业务框-功能说明”，这种描述的逻辑是：
了解功能，了解答题的功能内容-了解整体业务框架-进入细节了解，这种查看文档的交互方式，符合上述方法论，并且从浅往深引导查看参与者由浅至深的深入了解文档整体内容。
严谨的细节撰写
在整体框架的基础上，撰写的更深入。一方面，需要对行业业务知识进行积累；另一方面，对于所把握的产品功能的使用业务场景理解透彻。
在 产品需求文档A中，每个字段、操作逻辑、判断条件、业务场景无严谨的说明，所描绘的内容仅局限于不清晰的页面布局与不清晰的提取数据记录。而产品需求文档 B，采用格式化的形式进行文档撰写，在格式化的框架下，细致页面布局的字段与涉及业务场景、判断条件都能很好的进行描述。
而细节描述，尽量精确至每个字段。若所设计的字段与当前业务字段符合，请备注为当前功能不变，开发成熟的模块仅需要插进去。
但 业务场景，必须想清晰，如：在某款特卖产品中，新增”浏览记录”功能点，常规用户进行历史浏览记录查看时，超过90%的浏览的记录时“无法进行购买超 过”，这是影响用户体验，印象流量转化率。若后续在“本场景”下新增个性化推荐功能点，也显的有些不搭调，这个场景逻辑是：我看个人历史记录-没有了-推 荐其它商品，那我干嘛还看我的历史浏览记录？若针对于活动热度这种特殊场景，但是浏览记录又是一个常规功能。而事实上，这是非常典型的没将功能点各个业务 场景清晰的梳理清楚：
特卖商品拥有档期属性，若干天就需要对商品进行下架。
大量的用户非每天都会在本产品进行新商品浏览。（若是电商PM查看本文档，请查看贵平台后台的BI分析报表，查询一下日用户活跃度（DAU）的环比下降幅度，与用户平均查看商品数）
可理解的描述结构
产品需求文档A整体是缺乏结构的，而产品需求文档B是在结构化的框架下进行撰写。而描述结构围绕着产品功能或字段，围绕着“我是谁，我从那么来，我要那里去”，整体便非常清晰。
撰 写结构，是产品需求文档非常核心的组成部份，在模块化、排序、细节、结构等层面上。一方面，从整体上解决产品需求文档A存在PRD撰写的问题。另一方面， 将发散的思维收窄，聚焦至解决一个产品功能的业务问题上，包括字段数、业务逻辑、涉及的变量算法… ….清晰的描绘出来。
让PM把握产品功能整体，完整的的对价值实现上与下进行传递，并满足本章节提出的“撰写结构原则”条件。
三、开发思维
开发思维，是一种线性思维；在逻辑的世界里，只有“是与否”。是，则开始。否，则结束或进入下一个开始。
它们就像完美的整体，将产品从顶层战略至功能细节，体验在产品每个使用场景中（用户使用体验）（具体的用户体验，我们将从后续的篇章进行描述，这里不进行详细描写）。
正如在《倒爷教你写产品需求文档（基础篇）》中，计算机表达的是数据流与逻辑操作，那么开发思维，便是通过“是与否”，将产品细节，从数据流、操作逻辑关系的角度。描述出来；主要体现在两个方面：
数据流
在 协助层与基础层之间，通过“数据控制”与“数据传送”两个动作，实现数据的仓储与传送。那么，前台主要是进行取值（数据提取），后台主要是数据发布与管 理；而PM，需对所负责业务，对系统拥有哪些数据，与数据是如何控制拥有足够的把握。只要后台拥有产品功能模块数据，在不影响前台性能的前提下，在时间条 件充足下，基本上可以实现。
随着平台业务的增长，平台需从开始由于“低门槛”让参与度提高的策略，摆脱前期策略导致的信息数据匮乏。后期需逐渐逐渐通过运营的手段，将前后台的业务数据补齐，支撑后期进行数据结构化分析，实现数据智能精准化运营。而数据流，必然少不了。
逻辑关系
机器的行为，是通过程序语言来实现。你需要输入某个指令，它才会去执行某个任务。在处理多个任务的时候，便需要对多个指令进行判断执行。而在前后台业务时， 需要PM对每个业务状态场景有深入的认识，才能基于判断逻辑与触发条件足够的把控，将所负责的业务场景打通；（在这点上，若不是只做操作功能点的PM，可 以用户产品功能架构，将个人所负责产品功能，从数据发布、管理、提取、仓促、分析，进行产品功能框架搭建）
总而言之数据流与逻辑关系相互结合，能让PM在撰写产品需求文档时，让用户使用场景与计算机逻辑紧密结合，设计出符合用户体验的产品，结合业务场景进行功能取舍，设计出符合平台战略或用户体验的产品功能点，提高了对应的转化率与实现业务(GMV）增长。
四、综述
撰写结构与开发思维，是撰写产品需求文档非常核心的组成部分。是在模板或者样式的基础上，输出优质严谨的文档内容。在业务层面，与开发与业务方更严谨的进行良性沟通。而这些正是进阶版的核心所在，这个基础上，你可以根据实际的产品功能请看，进行PRD撰写与设计！
同时，将PM从发散思维的产物收窄至逻辑思维的产物，大大提高了PM入门门槛，提高了专业度。
五、附语
对于产品需求文档是否需要某类样式与格式？具体的样式与格式，可根据团队、项目实际流程与平台业务性质进行撰写结构进行设计，毕竟商业社会是以团队的形式进行作战。
但， 作为个人，是否需要进行训练。倒爷001无法给你明确的答案，因为那是你自己的事。但是，从PRD角度，撰写完整的框架，能对你个人的产品框架思维得到训 练。并且，文档是否高要求，其实也是你的事，至于开发看不看那是开发的事。出了问题，背锅的也是你的事。总不能让测试背吧？
大道至简，简难而繁易。处理一个功能点的框架思维与处理一个产品的框架思维是一样的。经过严谨的训练，能让框架思维得到提升，而初始框架搭建是否靠谱，也决定了产品后续的迭代生长。
六、抛个话题
如果上帝无法预测与控制宇宙的每个细节，在我们所能理解的所认知思维中，对我们存在认知进行设计，并存有大量以下的现象，如：
50%的人类是畸形人
50% 的天气是自然灾害
女性的占比率<=1%
那么，你认为Ta是一位伟大的创造者？
相关阅读：
