产品需求如何列出节点

⑴ 产品需求文档模板

首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。

不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。

要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：

一、描述-解释-预测-监控

描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。

解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。

预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。

监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。

二、需求准备、编写和检查

回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。

1. 描述

描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。

需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；

需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；

需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；

需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；

2. 解释

解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。

这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：

需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；

需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；

需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；

需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；

3. 预测与监控

预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：

预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。

解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：

需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；

需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；

需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；

需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；

在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。

四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。

写在最后

产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。

⑵ 【干货1】如何写好产品需求规格说明书（PRD）

PRD，即产品需求文档，是产品项目从概念化阶段过渡到图纸化阶段的重要文件。它不仅涵盖了产品的战略层面，也包含了战术层面的需求描述。PRD的主要用途包括：开发团队能从文档中获取整个产品的逻辑设计；测试团队据此构建测试用例；项目经理通过PRD拆分工作包，并合理分配开发人员；而交互设计师则根据PRD设计产品的交互细节。在项目启动前，PRD是必须要经过评审确定的最关键文档。

产品经理的PRD就像是建筑设计师的设计蓝图，是设计和思考的结晶，同时也是思考过程的呈现。其另一个重要功能是定义产品需求，并在团队内部达成共识。PRD文档常见的形式有Word文档、图片或交互原型。

Word版PRD是传统意义上的PRD文档，主要包含了信息结构、限制条件、业务流程、产品用例、非功能性需求等内容。该文档的阅读对象主要为技术人员，因此其目的是清晰地描述产品的功能需求，减少不必要的文字，让读者能够快速理解产品意图。在撰写时应尽量简化文档内容。

信息结构是产品结构的基石，类似于建筑设计时考虑的整个建筑的布局，包括美食区、服装区、百货区、休闲娱乐区等，每个区域又可以按照商家或类型进一步细分。产品的功能和内容按照维度组成频道/模块，最终形成完整的产品结构。

限制条件部分描述了产品的全局性需求，如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制等。例如，移动产品的“状态维持与恢复”需求，即用户退出产品后，系统需要保持用户操作前的状态，当用户返回时，系统能恢复到之前的操作状态，并继续使用。维持状态包括流程操作、信息浏览、文本输入、文件下载等，即使在锁屏状态，如果有下载任务，仍会继续进行。

业务流程分析有助于产品经理理解产品的逻辑，特别是涉及到多个角色的B端产品流程，可以使用泳道图来呈现，而C端产品则通常较为单一。在分析业务流程时，状态图和顺序图等工具也可以帮助梳理逻辑。

产品用例是描述流程中某个节点的具体需求，例如会员中心下的内容管理模块，其中包含的具体用例有新增文章、修改文章、删除文章、查看文章列表、查看文章详情等。每个用例都应该包含用例编号、用例名称、使用角色、优先级、描述、前置条件、后置条件、界面、规则描述和其它说明等内容。

描述产品用例时，规则部分尤为重要，主要涉及数据规则、状态逻辑和交互规则等。数据规则描述了页面从数据库获取并展示数据的规则，如文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则、刷新频率等。状态逻辑描述了不同状态之间的切换条件，如文章状态为已发布，变为下架可能的触发条件。交互规则详细说明了界面上存在的交互元素的规则，包括链接、按钮、滑动、下拉等具体交互规则及异常处理。此外，还需考虑网络问题、系统问题导致的异常情况。

非功能性需求涵盖了性能需求（如访问速度、最大并发用户数）、设计需求（如风格偏好）以及统计需求（如数据字段、报表生成）等内容。撰写PRD文档时，需要将这些非功能性需求考虑在内，以确保产品的全面性和实用性。

撰写PRD文档是产品经理的基本能力之一，良好的文档能力有助于提高团队间的沟通效率。本文提供了撰写PRD文档的基本框架和注意事项，希望能对读者有所帮助。下一篇文章将更深入地探讨PRD文档的撰写技巧，敬请期待。

⑶ 新产品开发中TR1,TR2,TR3..具体指什么

在新产品产品开发中，TR代表的是技术评审环节的节点。

以下对各个技术评审点的说明：

TR1——概念产生阶段技术评审点：产品需求和概念技术评审（业务需求评审）。

TR2——需求计划阶段技术评审点：需求分解和需求规格评审（功能需求评审，产品级规格）。

TR3——架构计划阶段技术评审点：总体方案评审（系统设计，架构设计，概要设计）。

(3)产品需求如何列出节点扩展阅读：

主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查，以找出和消除其中的缺陷。

技术评审为新手提供软件分析、设计和实现的培训途经，后备、后续开发人员也可以通过正规技术评审熟悉他人开发的软件。

评审小组至少由3人组成（包括被审材料作者），一般为4至7人。通常，概要性的设计文档需要较多评审人员，涉及详细技术的评审只需要较少的评审人员。

⑷ 我想做一个产品，产品的研发制作过程是怎么样的

大家好，我是隔壁丶老师，下面对一般产品的开发流程做旁派正一些介绍。

产品可以分为很多种，包括但不限于电子产品、软件、食品、首饰、服饰、机械、玩具等。

对于一般的产品，主要可以分为如下几个阶段：

1.产品策划与需求分析

2.可行性评估与制定开发计划

3.产品方案框架设计

4.产品方案详细设计

5.产品方案验证

6.产品小批量试产

7.产品首批试产

（高亮表示该阶段更为重要）

阶段1：产品策划与需求分析

这个阶段是所有的产品都应该仔细进行与完成的阶段，是为了明确产品开发目的，统一团队目标，判断是否能够开展的重要环节。

主要的任务为（不分先后）：

1.确定产品市场定位及目标消费人群。也就是分析将来谁会购买这个产品，如何进一步的满足他们的需求，年轻人/老年人，男性/女性，企业/个人，甚至是更为针对性的群体，区别很大。

2.规划产品性能和功能需求。性能是产品的核心竞争力，功能则为产品锦上添花，更要仔细的分析与规划核心功能。

3.初步规划产品成本。不仅是规划产品未来的生产成本，研发的投入成本也需要进行规划，特别是人力与时间、外包成本等，估算需要筹集或开销的资金，判断是否能够满足。

4.与竞品的对标分析。寻找市场上是否有相近似的产品，如果有，那么要考虑如何与现有产品竞争并击败他们，又或者是如何抢占市场份额；如果没有，则要考虑如何让客户接受新产品。

确定产品的特定要求。比如必须满足的法律法规、认证、生产许可要求，价格要求、外形特点、尺寸、结构形式、产品包装与材料等。

阶段2：可行性评估与制定开发计划

进入这一阶段，则是为了确认产品是否有可能在规划的时间与成本内被开发出来。

主要任务为（不分先后）：

1.确定产品技术的可行性。需要专业的技术人员从技术的角度评估现有技术能否满足产品开发需求，包括材料、运悔生产工艺、元器件供应等方面均需要进行考虑。

2.初步估计产品的成本。根据产品的可行性分析，将所涉及的主要元器件、材料价格等估算产品的大致生产成本，评估是否满足规划要求。

3.评估产品生产效率和生产规划。在产品开发的初期，就应当考虑是否有合适的厂家或者产线进行生产，如果没有，则需要进行仔细的评估。

4.元器件与材料供应情况评估。产品所需的元器件或者材料是不是需要定制，或者都是易于采购的标准间，供应商的供货能力与周期，甚至运输周期、费用等问题，都将直接影响到产品的研发周期。

5.检验检测能力评估。产品的性能与功能如何进行检测，特别是如何判定是否满足强制性的法律法规要求，也是需要进行考虑的问题。

6.确定产品的开发周期与节点。计划好开发的时间节点，分配好各项任务的负责人，进而对整个项目进度进行监控，是做好产品开发的有效管理手段。

（产品的性能、功能与成本永远是产品开发所需要进行权衡与考量的关键所在，到底向哪方面妥协，都可能影响到产品最终的效果）

阶段3：产品方案框架设计

在确认了产品方案可行后，就要对产品进行初步的设计与验证。进一步的确认产品技术方面的可行性。

主要任务为：

1.制定产品大致方案。

2.将关键元器件组装成初代实验机进行实验，判断性能、功能等关键项目是否满足要求。

3.参照相关测试标准，对初代实验机进行测试。如果不能通过，则需要更换方案再次进行测试，直至满足要求。

4.根据测试结果，确定产品的大致方案。包括元器件选型、结构方案、电气方案、控制器方案、操作软件、包装方案的初步确定。

阶段4：产品方案详细设计

这一阶段是产品研发制作最关键，也是难度最高的部分。将方案从框架落实到产品的各个方面，都将面临一道又一道的考验，一次又一次的修改方案与测试。

主要任务为：

1.按初步设计方案采购与制造相应的元器件材料，制造或组装一定数量较为完整样机。

2.参照相关测试标准（国标、认证标准、企业内部标准等），对初代实验机进行测试，检测并判断各项设计指标是否符合设计要求与标准要求，并根据测试结果进行针对性的改进，直至能够同时满足所有的标准要求与产品开发需求。

3.根据测试结果与改进后的方案，确定产品各设计板块的最终方案。

阶段5：产品方案验证

这一阶段的目的，是对方案进行最终的确认，再次验证产品设计是否满足需求。

1.按最终方案，模拟实际生产组装一定数量的完整样机。

2.参照相关测试标准（企标），对实验机进行全面测试，检测并判断各项设计指标是否符合设计要求与标准要求。

3.全面考察产品的方案是否满足需求（各板块必须全部合格）。

4.对于一些需要进行认证的产品（如3C认羡铅证、生产许可证、CE认证等），需要准备相关资料与手续，进行认证工作。

5.根据产品需要，申请相关专利、软件着作权等知识产权保护。切记在产品公开之前完成专利的申请工作。

阶段6：产品小批量试产

这一阶段是为了用较低的成本测试产品的生产效率，以及寻找优化生产效率的可能性，排查在实际生产过程中导致的产品不合格的因素，提升良品率。

1.使用经过验证后的产品方案，在实际生产线正式生产一定数量的产品，考察产品的生产效率。

2.参照相关测试标准（企标），对产品进行抽测，分析产品的合格率以及良品率是否满足要求。

3.根据发现的问题，进行针对性的优化，如改动过大，可能需要再次进行产品方案验证。

阶段7：产品首批试产

本阶段与小批量试产的区别只是产品生产数量上的区别，可能在实际的产品开发中忽略这一阶段。

1.按小批试产通过后的（整改后）方案，在实际生产线正式生产一定数量的产品，考察产品的生产效率。

2.参照相关测试标准（企标），对产品进行抽测，分析产品的合格率以及良品率是否满足要求。

3.根据发现的问题，进行针对性的优化。

经过了上述七个阶段，并且全部通过后，产品就可以正式的定型了。

后续在销售与客户使用中接收到的反馈，可以对产品进行改进，或者开发新一代的产品。

当然，上述的阶段在实际的产品开发过程中，不一定是一步一步的进行，有些阶段可能进行了合并或简化，一些阶段可能会同时进行。这也取决于开发团队的管理模式、生产规模与实际需求。

作为一名过来人，建议大家在产品开发的过程中，做好更多的前期工作，以及在设计中留有改进的余地或者空间，以防项目在后期需要修改而导致对前期的方案推倒重来，造成不必要的损失。

以上，就是一个产品的大致研发制作过程。希望能够对大家有所帮助。

1产品的设计:产品的业务模型与流程要设计好，如果有UI的话先做好UI模型，把整个产品原型完全程序出来。

2技术选型与架构设计。产品原型出来后就可以进行技术选型，根据产品的要求，选择最高效与简洁的技术方案。技术选型完成后就可以进行整体架构设计。如果产品比较复杂，做完架构设计在分模块进行详细设计，具体到模块功能的设计，业务流程，接口定义等。

3开发与测试阶段。技术方案出来后评审通过，就可以按设计进行开发。开发过程涉及到细节与设计冲突或不明确，可以讨论再进行修补方案。开发完成后一般开发先进行基本功能的单元测试，单元测试完成后提交版本交付给系统测试（黑盒测试），测试与开发过程中可能有多次驳回与重提版本的过程。

4测试完成上线。产品测试通过后就可以准备服务器部署上线。一般由运维人员部署上线。

5产品运营。产品上线后交付与运营人员进行运营。

6产品迭代。产品运营过程中，有反馈需求的可以对产品再进行迭代开发，不断完善产品。

互联网产品，如果需求确定的话，按大公司的流程一般是这样的

一、产品经理根据需求画原型图

二、调配开发资源，协调后端开发工程师，前端开发工程师

三、以最小化可运行单元迭代开发，一般以周为单位

四、协调运维分配机器，然后上线

当然如果需求和立项都不确定的话，也需要花很长时间确定需求，计算投入等预算

如果是创业初期就不用考虑那么多了，自己确定好方向找个开发，最好前端后端都会的，开编码就好了，一切从简。

如果是其他实物类商品，那就找代工厂吧，一般都有，你设置好图纸，人家基本会定制做。