PRD产品开发项目 管理规范
产品开发项目管理规范
产品开发项目管理规范1．目的为保证产品开发项目规范运作，实现开发项目资源有效运用，使所开发产品符合成本效益并满足客户品质和进度要求，特制定本规范。
2．范围技术开发部门和参与产品开发过程的相关部门。
从新产品开发建议阶段到第一次量产的全过程。
3．组织每个新产品开发都成立一个项目组，项目组是一个临时组织，根据项目需求组成项目组，项目结束后项目组解散。
由开发部门牵头组成项目小组及任命项目经理，实行项目经理负责制。
市场部门、采购部、生产计划部、品管部、财务部、相关车间在成立项目组的同时分别指定专人配合项目组工作。
其中生产计划部分别指定工艺一人、计划一人。
项目组成立后经公司管线副总（重大项目常务副总或总经理）批准后开始运作，直到产品第一次成功量产后项目组工作结束，项目组解散。
4．项目管理项目经理负责跟进整个项目开发过程（开发流程见附件一：《新产品开发流程图》，详细的开发过程控制见附件二《新产品设计开发控制程序》）。
制定详细的项目开发计划，在整个项目开发过程中，项目经理每周六前提交本周《周工作报告》，并更新PAR；项目开发小组成员每周五下班前提交工作周报。
项目周工作报告和工作周报是个人考核和奖励的重要依据之一。
4.1 概念阶段市场部门提出新产品开发建议，填写并提交《新产品开发建议书》。
开发部对建议书提出的产品要求进行技术可行性分析，填写《技术可行性分析报告》，给出技术方案、人力资源及时间投入，列出主要材料清单及初步成本、测试、认证等费用。
采购部配合核实材料、模具、手板等成本费用。
财务部核算初步成本效益。
主管副总审批开发建议书，通过后成立项目组。
开发部启动项目开发，进行手板制作；采购部配合进行打样工作。
手板制作完成后提交给市场部及主要客户，并收集反馈信息，形成PAR报告和制定标准产品规格书4.2 开发阶段在新产品手板得到客户认可后，市场部门提出新产品立项申请（不用开模的简单产品开发、产品升级改进不用提交立项申请），填写并提交新产品立项申请书。
详解产品需求文档(PRD)
详解产品需求文档（PRD）PRD是英文“Product Requirement Document”的缩写，翻译为中文就是“产品需求文档”，主要用于完整描述产品需求，向研发部门明确产品的功能和性能。
PRD的面向对象是研发部门，用于向他们说明需要开发的产品功能和这些功能的性能要求。
PRD质量的好坏，在很大程度上不仅直接影响着研发部门是否可以明确产品的功能和性能，而且在很大程度上决定了产品的最终质量。
NO.1 PRD的主要内容一份完整的PRD文档主要包含两部分内容：一是对项目的介绍，包括项目概述、项目价值、项目背景等；二是整份文档的主体部分，对产品需求的详细描述，包括功能需求和非功能需求。
对于不同的公司、不同的项目类型，PRD包含的内容会有所差异，但一般来说，比较常见的PRD都会包含版本修订记录、项目概述、项目价值、项目背景、场景描述、功能总表、业务流程图、用户界面、功能描述、非功能描述、附录等模块。
下面是一份比较常见的PRD的目录。
目录1.项目概述2.项目价值3.项目背景4.功能概述4.1场景描述4.2功能总表4.3业务流程图4.4 功能描述4.5 数据监控需求5.用户界面6非功能需求7.附录NO.2 产品功能的描述用户界面和功能描述是PRD最重要的两个部分，用户界面主要是以产品原型作为载体，用直观图形的形式展现产品的功能，功能描述则是在用户界面的基础上，以文字的形式诠释产品功能的细节，使开发人员更清晰地明白产品功能性能的要求。
对产品功能进行描述，一般需要两个步骤：第一，梳理产品功能描述部分的整体结构，有规律地将产品功能分成多个较小的功能单元，并确定描述的先后顺序。
比如，在产品功能具体的分解时，可以按功能在系统中的位置、按业务流程、按功能主次、按功能所处界面位置等进行分解。
第二，以用例的形式描述分解后的产品功能。
用例指的是在不展现系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。
产品经理基本功之PRD
产品经理基本功之PRDPRD (产品需求文档), 英文全称是：Product Requirement Document。
PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD或BRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
产品经理工作中最重要的产出是独立撰写一份PRD，这是产品经理的基本功之一。
怎么理解PRD产品需求文档，即Product Requirement Document是产品经理能力基础中的基础是从产品规划到产品设计阶段的里程碑式综合产出物“PRD写的好，不一定是好的产品经理，PRD写的不好，一定不是好的产品经理。
”今天我们就来谈谈这个基本功的话题——怎么样写出一份高质量的PRD。
如果你看完一份PRD也有以下感受：•文档通篇是各类名词、页面功能点跳转、点击之类的逻辑；•看完了文档有一肚子的疑问：为什么要有这个功能，为什么要这么做产品设计；•第一遍头晕眼花，必须得看第二遍、第三遍才能明白功能之间的关系。
这确实是一份不友好的PRD。
这种PRD产生，主要由于以下两个问题：1、产品经理以为没写出来的那些内容，研发都已经潜在知晓了、明白了，或者作者打算“PRD评审的时候我会说这些内容的”。
2、产品经理撰写到PRD里面的，只是自己产品设计的结果，就是用例、功能、交互。
第一个问题——“想不如说、说不如写。
想不明白肯定也写不清楚。
”大家可以挑战一下自己，把那些打算放在评审会说的话，都先写在PRD里面。
第二个问题——产品经理把PRD评审当做一次功能宣讲，只关注“让研发需要开发”的功能点（只说结论），忽略了其他也应该同步给项目团队的其他核心内容以便达成共识，导致开发过程的衍生问题，每次多要事无巨细的去讨论、争论。
这两个问题如何解呢？先从PRD的作用说起吧。
PRD的作用作用一：PRD是项目工程人员围绕其进行技术落地的设计图纸。
prd文档的几个要素
prd文档的几个要素摘要：1.PRD 文档的概述2.PRD 文档的几个要素3.PRD 文档的重要性4.PRD 文档的实际应用正文：PRD 文档，全称为产品需求文档，是产品经理在产品设计和开发过程中，用来描述产品需求、功能和特性的重要文档。
一个好的PRD 文档不仅可以为产品团队提供明确的指导，还可以帮助产品经理在项目推进过程中，更好地与团队成员沟通和协作。
本文将介绍PRD 文档的几个要素，以及如何编写一份优秀的PRD 文档。
首先，我们来了解一下PRD 文档的概述。
PRD 文档是一份详细的文档，它包含了产品的所有需求和特性，以及产品设计和开发的详细计划。
这份文档通常由产品经理编写，用来指导产品团队的工作。
在编写PRD 文档时，产品经理需要考虑多个因素，包括产品的目标用户、产品的功能需求、产品的特性和产品的用户体验等。
接下来，我们来介绍一下PRD 文档的几个要素。
一个好的PRD 文档通常包含以下几个要素：1.产品概述：包括产品的目标用户、产品的功能需求、产品的特性和产品的用户体验等。
2.功能需求：描述产品需要实现的功能，以及这些功能的具体要求。
3.特性需求：描述产品的特性，例如性能、安全性、可扩展性等。
4.用户体验：描述产品的用户体验，包括用户界面、用户操作流程等。
5.非功能性需求：描述产品的非功能性需求，例如性能、可靠性、安全性等。
6.产品设计：描述产品的设计思路和设计方案。
7.开发计划：描述产品的开发计划，包括开发周期、开发人员等。
以上就是PRD 文档的几个要素。
在编写PRD 文档时，产品经理需要考虑这些要素，并根据实际情况进行适当的取舍和调整。
PRD 文档的重要性。
PRD 文档是产品设计和开发的重要指导文件，它可以帮助产品经理更好地与团队成员沟通和协作，提高工作效率。
此外，PRD 文档还可以为产品团队提供明确的指导，避免在设计和开发过程中出现偏差。
最后，我们来介绍一下PRD 文档的实际应用。
在实际应用中，PRD 文档通常用于以下几个方面：1.产品设计和开发：PRD 文档是产品设计和开发的重要指导文件，可以帮助产品团队更好地理解和实现产品需求。
项目管理及发布规范
项目管理及发布规范(GB2011-001)麦网开发部2011年５月10日修订历史记录一、项目开发管理综述1、项目基本流程图一PRD项目开发流程2、流程角色及说明二、PRD流程及规范PRD流程分为PRD调研、PRD Review、PRD分析、PRD确认四个步骤。
●PRD Review：由产品经理、开发团队成员、测试人员共同Review。
PRD Review后，如果仍有较多问题，需要产品经理修改后，重新Review。
●PRD分析：PRD Review通过并提供最新版本后，开发人员根据PRD进行初步的PRD详细分析与ERD设计。
分析包括所有功能模块的实施方案，解决开发中可能出现的所有问题，及时对PRD的问题提出疑问和修正意见。
PRD分析过程中，应同时进行ERD的初步设计。
PRD分析完成后，项目的所有成员，应对PRD有深入的理解。
●PRD确认：PRD详细分析完毕后，则为PRD确认。
PRD确认后，应将确认的PRD加入项目的Documents目录中，同时，将PRD发给测试部李颙备案。
注意：PRD确认后，开发和测试过程中，除开发团队认为PRD仍有问题或不明确的地方需要调整外，不可随意修改与调整PRD，包括文字与内容。
PRD调整应经过开发总监确认后，并提交新的PRD文档给测试、开发备案后，才可接受更改。
三、项目开发流程及规范开发流程分为：开发计划、ERD详细设计、开发、自测、Code Review五个步骤。
●开发计划：PRD分析并确认后，项目主管应对项目的进度安排做详细计划。
开发计划应包含ERD设计和Review、项目编码、自测、Code Review、项目部署计划及部署测试等各方面的时间。
●ERD详细设计：开发负责人在ERD初步设计的基础上，细化ERD设计。
（ERD设计要求，见ERD设计模版）●ERD Review：ERD详细设计完成后，由开发负责人、架构师、开发总监共同ReviewERD设计，以评估方案的可行性、完整性和优劣性，并及时修正方案。
prd文档 范例
prd文档范例【以《prd文档范例》为标题，写一篇3000字的中文文章】一、什么是PRD文档PRD（Product Requirement Document，产品需求文档）是一种非常重要的项目文档，它是产品团队进行产品开发的重要依据，也是各方参与者（开发、测试、运营、市场、设计等）对外的交流文档。
PRD文档的主要内容包括：1.标：给出项目的目标、指标以及实施该项目的利益依据；2.决方案：详细描述产品功能、性能及要求等；3.术实现：根据客户需求和开发能力，提出合理的技术实现方案；4.源投入：要求客户和开发团队投入资源，如人力、财力等；5.间节点：给出项目实施的时间节点和计划；6.险控制：明确项目最终要达到的安全等级及风险的控制要求；7.控与维护：说明产品的维护流程，以保证产品的稳定运行。
二、PRD文档的编写1. 了解客户需求首先，作为编写者，要首先了解客户需求，并且仔细揣摩客户真正所需要的产品特性，分析客户的真正意图，把握客户的期待和要求，确保最终成果能够满足客户需求。
既然对客户需求有了一定了解，接下来应该开始整理和核实需求。
产品需求应该清晰明确，与客户期望的一致，且不能有太多的歧义。
3.析可行性需求搞清楚了，接下来要做的就是分析可行性，解决方案需要合理可行，考虑技术实施、资源投入、时间安排等多方面因素，确保最终产品能够达成客户期望。
4.定实施方案经过以上步骤，我们应该确定项目的实施方案，并且包括具体的解决方案、技术实现、资源投入、时间节点等。
5.写核实最后就是编写及核实文档，文档要清晰、明确，结构要完整、合理，语言要准确、简洁，内容应包括项目的概述、目标及期望、实施内容、时间节点等。
三、PRD文档编写范例产品名称：XXX新型AI设备客户：XXX公司1.项目目标本项目的目标是研发一款新型的AI设备，为用户提供全面、智能的服务，以实现满足客户需求、增加产品价值、促进销售和提升客户满意度的目标。
我们将设计一款全新的AI设备，该设备能够根据用户的行为和需求，智能分析并实现智能匹配，实现数据挖掘、机器学习等，提供个性化的服务。
prd的流程-概述说明以及解释
prd的流程-概述说明以及解释1.引言概述部分的内容可以描述PRD的流程是什么，以及它在产品开发中的重要性。
下面是一个可供参考的示例：1.1 概述PRD（Product Requirements Document）是产品开发过程中不可或缺的重要环节，它作为产品管理和开发的基础文件，定义了产品的功能、性能、用户需求以及产品规格等方面的要求。
PRD流程是一个系统化的过程，它涵盖了产品规划、概念设计、需求收集、需求分析、功能设计、测试验证、发布等多个阶段。
在这个过程中，PRD扮演着沟通桥梁的角色，连接了产品经理、设计师、开发团队、测试人员和其他相关人员之间的合作。
PRD的编写需要充分了解产品的市场定位、目标用户和业务需求，同时要与设计和开发人员紧密合作，确保产品能够满足用户的期望和需求。
通过对功能、界面、交互等方面的详细描述，PRD可以帮助团队明确产品的功能范围、需求优先级以及开发进度。
PRD的重要性体现在以下几个方面：1. 提供明确的目标和方向：PRD清晰地定义了产品的功能和性能要求，为产品团队提供了明确的目标和方向，帮助团队聚焦于核心需求，避免在开发过程中偏离主线。
2. 消除沟通障碍：PRD作为产品需求的书面表达，可以帮助产品经理向设计师和开发人员传达清晰的信息，减少误解和沟通障碍，提高团队的工作效率。
3. 确保产品质量和用户满意度：PRD作为产品规范的参考文档，可以在产品开发过程中对功能进行验证和测试，确保产品的质量和可用性。
同时，PRD也能够帮助产品经理识别和解决潜在的问题，提高用户的满意度。
总之，PRD流程在产品开发中起着至关重要的作用。
通过明确的需求描述和协调团队合作，PRD帮助产品团队将创意转化为实际可行的产品，提供给用户更好的体验和价值。
在接下来的文章中，我们将深入探讨PRD 的定义和它在产品开发中的重要性。
1.2 文章结构文章结构部分主要介绍本文的章节划分和各个章节的内容安排。
在本文中，文章结构可以按照以下方式组织：1. 引言：在这一部分，将对PRD的流程进行引言，说明本文的研究背景和目的。
产品开发——产品需求文档(PRD)
产品开发——产品需求文档（PRD）
产品需求文档（PRD），是产品开发的基础文件。
研发人员通过PRD了解到产品开发的方向和具有的功能如何。
项目经理通过对PRD的分解将资源进行分配。
如何写好一份产品需求文档，前面我们讨论过如何做竞争产品分析，以及竞争产品分析在产品开发中的影响。
我们产品的需求的功能要求多数来之竞争产品，一份需求文档，会影响到后期落地的产品与竞争产品的差异。
只有产品有差异加上不同层次的定位才有定价权。
不会落到价格竞争这种比较低级的竞争状态。
比如：我们使用的智能手机，苹果与其他产品的差异化（包括软件和硬件的集合）在竞争产品中处于高端定位，它就具有相关的定价权。
其他使用安卓系统的产品，使用的芯片和系统相差无几，如何保证自己产品的差异化，其使用的手段就是进行二次再开发，和工业设计的迥异，以保证产品的差异。
那么一份产品需求文档包括哪些内容呢？
一，开发的目的
二，面对的市场
三，产品造型
四，具体功能要求（具体使用的工具有，mindmanager,visio,axure......等等，创建模型和流程的工具）
五，其他需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
产品开发项目文档管
理规范
文档编号：COSHIP-CMMI-PRD-PDPDM
密级：机密
版本信息：1.8
批准日期：
编辑软件：Microsoft Word 2003 Microsoft Visio 2003
同洲电子股份有限公司版权所有
内部资料注意保密
*变化状态：C――创建，A——增加，M——修改，D——删除
目录
1 概述 (1)
1.1 目的 (1)
1.2 适用范围 (1)
2 产品开发文档体系 (1)
3 文档质量的度量准则 (3)
4 主要角色和职责 (3)
4.1 文档作者 (3)
4.2 项目经理 (4)
4.3 PPQA (4)
4.4 配置管理工程师 (4)
4.5 评审组 (4)
4.6 部门经理 (4)
5 文档审核流程 (5)
5.1 审核流程 (5)
5.2 归档签名 (6)
5.3 纳入基线 (6)
6 文档保密制度 (7)
7 文档编号 (7)
7.1 文档编号规则 (7)
7.2 阶段代号 (8)
8 文档版本 (9)
1概述
1.1 目的
规范公司产品开发项目的文档体系，加强文档的标准化管理。
1.2 适用范围
公司内所有产品开发项目。
2产品开发文档体系
在产品开发项目开发过程中，各阶段都有相应的文档输出，文档的编写应先于或同步于开发工作。
产品开发项目过程中的文档体系如表1所示。
表1.产品开发项目文档体系
3文档质量的度量准则
评审文档质量的度量准则有以下六条：
完整性：所承担产品开发任务的项目组，需按照公司文档体系的规定编写相应的文档，以保证在项目结束时其文档是齐全的。
正确性：在项目各个阶段所编写的文档的内容，必须真实的反映阶段的工作且与该阶段的需求相一致。
文档与所述的对象保持一致，必要时应进行实时的文档版本升级。
可读性：文档应该表达清晰、逻辑条理分明、表现形式通用。
简明性：在项目各个阶段所编写的各种文档的语言表达应该准确简练。
规范性：文档的规范性是指采用当前最新的模板。
其完整性及内容的充实程度应不低于模板的要求。
可追溯性：在项目各个阶段所编写的各种文档应该具有良好的可追溯性。
由于各开发阶段编制的文档与各阶段完成的工作有着密切的关系，前后阶段生成的文件，随着开发工作的逐步扩展，具有一定的继承关系。
在一个项目各开发阶段之间提供的文件必定存在着可追溯的关系。
4主要角色和职责
4.1 文档作者
文档作者包括公司内的项目组成员以及外协人员。
文档作者在文档方面的主要工作为：1）在项目开发过程的各个阶段中，按照规定及时地完成项目文档的编写工作，文档作者有责任保证文档编写与开发同步。
2）文档作者不仅要审核文档字面上有无错漏，还要审核所陈述的技术内容是否精确，及表达方式上是否清晰易懂。
文档作者对文档的正确性、可读性和规范性全面负责。
3）文档作者保证所编写的文档与所描述的对象保持很好的一致性，必要时及时更新文档，便于以后维护工作和后续开发工作的开展。
4.2 项目经理
项目经理是控制文档准确性的关键环节，项目经理与文档作者一起构成文档正确性的直接责任人。
项目经理在文档方面的主要工作为：
1）项目经理制定整个项目的文档计划（包含在项目计划中），并督促落实文档计划的实施。
2）负责对技术内容正确性的检查并校对文档内容与所述对象最新版本是否保持一致。
3）定义项目文档的密级。
4.3 PPQA
PPQA的主要工作为：
1）对文档作者提供的文档进行编号。
2）检查项目各阶段文档计划的执行情况，确保文档的三级审核制度得到执行直至最后归档。
3）对文档进行规范性审查。
4）根据文档计划，组织评审组对文档进行评审。
5）确认项目经理定义的文档密级，并确保文档的保密性得到有效控制。
4.4 配置管理工程师
将评审通过或是部门经理审核通过的文档纳入基线管理，根据密级确认相应的权限。
4.5 评审组
对需要评审的文档（可行性研究报告、项目计划书、需求规格说明书、概要设计书等）的内容进行质量把关。
4.6 部门经理
文档作者所属部门的部门经理对不需评审的文档进行最终审核。
5文档审核流程
对每一份文档要求在纳入基线前，从项目经理、PPQA、部门经理或评审组，进行三级审核，这样，分别从文档质量的完备性、正确性、可读性、简明性、规范性、可追溯性等方面进行分层把关，并最后签字确认其文档质量合格。
产品开发项目的文档管理层次结构如图1所示：
5.1 审核流程
产品开发项目文档在归档前均要经过多级审核，各审核一般都对应到文档封面的签名。
文档的审核归档流程如图2所示。
图2 文档的审核流程
5.2 归档签名
开发阶段文档在纳入基线之前需要经过三级审批，包括文档作者在内共四级签名：
➢文档作者：为文档的主要思想提供者和写作者。
如果有多人参与，则记录主要人员。
➢项目经理：为在立项评审时指定的项目负责人。
➢审核：PPQA。
➢批准：如果此文档需评审，则批准人为评审组长；否则为文档作者所属部门的部门经理。
5.3 纳入基线
产品开发项目文档在经过三级审批通过后，由配置管理工程师纳入基线进行管理。
6文档保密制度
为确保产品开发项目文档的安全性，防止技术资料的外泄以及维护公司的权益，对每种文档还应划定它们各自的保密级别。
每份文档的密级原则上根据其所含技术的保密要求以及产品进入市场的程度，由项目经理负责指定。
文档是按照与开发同步的原则写作，所以大多数文档在第一次纳入基线时，其密级一般为“机密”，然后随着产品的逐渐成熟，其保密程度会逐渐放开，所以每份文档的密级标志是动态的。
纳入基线后的文档密级若需要改变，可由项目经理提出申请，配置管理工程师责对文档所在配置库重新分配权限。
文档密级共分为四级：
➢绝密：指只有极少数人可以查阅的文档。
如：核心技术的文档、预研项目的文档等。
此类文档应严格保密，配置库权限一般只分配给研发领导指定人员，须签订保密协
议。
➢机密：指只有项目组的人可以查阅的文档。
如：《软件概要设计说明书》、《硬件概要设计说明书》等。
对此类文档，配置库权限分配给项目组成员，其他人如需申请
权限，需经项目经理批准。
➢普通：指在公司范围内开放的文档。
如：《产品规格》等。
此类文档可在公司范围内进行传阅。
➢公开：指对外开放的文档。
如：《产品说明书》及相关宣传资料等。
对此类文档不做权限控制。
以上密级归类仅供参考，各项目经理应根据产品竞争策略需要等实际情况确定归入哪个密级，做到在保密基础上的资源共享。
7文档编号
文档以产品和项目为单位进行划分，对每篇文档根据其所属产品、项目和具体描述内容定义一个唯一的编号。
文档编号由PPQA分配。
注：硬件原理图、PCB图、结构图纸、BOM等文件编码不在此编号范围内。
7.1 文档编号规则
文档编号由五部分组成，各部分由‘-’分隔，其构成如下：
产品型号_项目编号_阶段代号_模块代号
对文档进行编号时，各组成部分最好都有对应的代号及含义。
如果不需区分模块，则以‘&’代替模块代号。
其中：
➢产品型号：一般对应于产品型号（外部型号）。
➢项目编号：所开发产品的项目编号。
➢阶段代号：此文档对应的项目阶段代号，请参见7.2。
➢模块代号：软件功能模块或硬件单板的缩写。
如：新华社项目设计阶段的设计文档《MPE模块概要设计书》的文档标号为：CDVB5110G_ DC-P071114-21_PD.SW_MPE。
7.2 阶段代号
阶段代号由2～4位英文字母和一位“.”字符表示，构成如下：
主阶段代号.子阶段代号
1～2位1～2位
例如，“可行性研究报告”文档对应的阶段编号为I.R,“系统测试计划”文档对应的阶段代号为SA.TP。
文档各阶段代号如表2所示。
表2.文档阶段代号
8文档版本
版本编号由2位数字组成，以“.”来分割。
例如：V3.1表示：主版本为3，副版本为1，开发文档初始版本为V1.0。
具体请参见《PRD-版本管理规范》。