《产品项目管理规范.docx》由会员分享，可在线阅读，更多相关《产品项目管理规范.docx（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、密级：保密口馈目治理标准编写日期：2021-2-5北京XXX科技地址：北京市西城区XXX室：XXX: 010-xxxxx : 010-xxxxxxxx立项工作单提交日期期望完成日期工程阐述工程需求及设计重要性高口中低紧急性高口中低需求发起人产品经理所属部门主管签章工程实施评估及审批工作量人/日预期开始开发时间预期完成时间是否需要提交原型口需要口不需要工程风险度低口中口高评估意见评估人签字：参与开发人员技术总监签字产品总监签字CTO签字产品治理签字工程暂停/取消一恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品治理签字恢复时间产品总监签字技术总监签字产品治理签字工程完毕审核实际完成时
2、间测试工程师签字是否延期口是口否原因：是否发布同意不同意产品治理产品经理签字产品总监签字技术总监签字CTO签字备注：工程相关物料规划文档是否提交口功能规格说明书是否提交口需求分析说明书是否提交口产品设计原型是否提交口产品使用说明书是否提交一 一，需求变更工作单事件/工程名称需求编号需求修改原因提交日期期望完成日期修改类别口添加新需求口修改原需求重要性高口中口低紧急性高口中口低需求修改阐述需求修改描述需求提交人产品经理影响分析对原需求影响程度高口中低受影响部门受影响部门意见产品经理产品治理工作实施方案及审批工作量人/日开始开发时间预期完成时间风险度低口中口高评估意见评估人签字：是否需提交原型口需
3、要口不需要指派技术负责人技术总监签字产品总监签字工程暂停/取消一恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品治理签字恢复时间产品总监签字技术总监签字产品治理签字工作完毕审核实际完成时间产品治理签字是否延期口是口否原因：是否发布口同意口不同意产品经理签字产品总监签字技术总监签字目录目录错误!未指定书签.1 .文档版本限制错误!未定义书签.文档说明错误!未指定书签.文档更新纪录错误!未指定书签.2 .职能错误！未指定书签.产品治理部错误!未指定书签.需求治理员错误!未指定书签.技术部/ 软件部错误!未定义书签. 需求提出人员错误!未指定书签.3 .需求判别流程错误!未指定书签.4
4、.工单治理流程错误！未指定书签.5 .产品制作流程错误!未指定书签.5. 1立项阶段流程错误!未指定书签.6. 2研发阶段流程错误!未定义书签.6 .需求变更流程错误!未指定书签.7 .附录错误!未指定书签.7. 1文档命名规那么错误!未指定书签.附件一：事件工作单错误!未指定书签.附件二：立项工作单错误!未指定书签.附件三：需求变更工作单错误!未指定书签.L文档版本限制文档说明本文档为金色经纬工程治理流程专用说明文档.文档总括性的表达了因需求可能产生的工程/事件的 制作流程，以及各个阶段的划分方法和工作产物.本文不包括产品开发过程中各个角色的工作流程，具体工 作流程请参考各个部门的具体工作流
5、程文档.文档主要包括以下内容：1 .小型工程/事件治理流程；.产品化工程治理流程；2 .需求变更治理流程；文档更新纪录作者日期版本内容参与者备注罗心晶2021-2-52.职能应当阅读此文档的人员为任何参与到产品开发过程中的角色,包括：中高层治理人员总监及高管）、产品筹划人员、技术开发人员、运维人员、市坳销售人员.重要角色包括：产品治理部、需求治理员、产品经理（需求提出人）、技术人员.其中对重要角色职能及相关要求定义如下：产品治理部负责产品和工程开发标准的制订,并监督其执行情况.需求治理员检查相关文件,签名是否齐备,落实阶段需求文档到位，向开发人员提交开发任务，负 责将需求,工程状态更新到 TD
6、,Project Server 中.技术部/终端部所有开发需求必须经过产品治理部需求治理员同意,确认方可开始进行开发；发布人员必须经过需求治理员同意, 确认签字方可发布程序.需求提出人员工作量大于1人/天的任务,必须经过需求治理员同意，确认前方可提交给开发人员.3.需求判别流程根据公司现阶段开展及实际工作情况，总结因需求可能产生的工程/事件,发起的过程相同,整理归纳大致流程 如下：其中关键部份为判断需求级别.产品经理发起需求草案,并与技术部进行可行性分析和工作量预判工作,根据技术部提供的建议对方案进行 调整；并根据调整后的需求草案发起讨论会议.在会议上将确认该需求进入相应流程.草案需求讨论会议
7、 为非常规流程，但判 断需求级别最简要求：CT0或C00签字或邮件确认；需求类型分两种：需求变更一一对已实施产品或工程进行变更需求；新需求一一新需求根据工作量及重要性分为工单和工程两种流程;判断新需求级别分类工程工程工单说明：现技术局部为两个工作组,一组5人,一组7人,工作量评估建议以重要性较高,且独立 工作组一半人数以上/日列为工程 进入工单治理流程一一产品经理启动?事件工作单?，产品总监&技术总监签字 或回复邮件确认生效； 进入产品化工程治理流程一一产品经理启动?工程工作单?； 进入需求变更治理流程一一产品经理启动?需求工作单?.经确认需求为工单,应进入如下流程：产品经理需填写?事件工作单
8、.doc?（见附件1），描述事件要点，并单独附事件详细设计文档,交由产品治理进行 分析评估，如需求与事件工作描述差异较大，或事件工 期超过3个工作日，将提交产品总监&技术总监确认，明确开发 要求及需求后，转交技术部相关负责人进行研发并跟踪进度.如事由紧急,事件需求负责人可直接以邮件/文档等形式向产品总监&技术总监确 认,技术总监确认同时安排指定 工程师，确认同时抄送产品治理组进行限制及跟踪进度.启开工单流程后,在整个研发过程中状态如下：进入暂停状态后，如需恢复,重新启用工单流程.5.工程治理流程如判断某个草案将形成产品化工程,应按以下流程进行治理和限制.除指定物料和 里程碑,所有细节可由具体操
9、作 人自行把握，.工程治理流程将产品的制作过程分为两个局部：立项阶段和开发阶段.经过这两个 过程后，产品将脱离制作流程, 进入运营流程.运营流程的具体情况请参阅运营流程文档.为了更清晰的表达各个阶段的进行流程，给出一个整体示意图：在每个阶段中,工程将分割为如下状态：下面对于每一个过程,分别给出流程图,并对整个流程的概述.流程中的每一个 阶段,都将安排一个评审会议,在 评审会议上,产品、技术、治理测试和市场/销售代表对相应的提交物进行评估和评论，其目的是在每一个阶段增强公 司内部各个部门对产 品整体质量、进度的了解和熟悉,并在下阶段优化和改良产品.从另一方面说,如果工程进展或 质量达不到要求的话
10、，任何一个阶段评审会,都给高层治理一个终止工程,规 避风险的时机.在整个工程治理流程中，以下物料分别为各个阶段的必备文档，产品经理应严格遵从模板样式，按时提交：规划文档（可为邮件,大纲等非正式文档一一规划阶段；功能规格说明书（模板待定）一一概计阶段；需求分析说明书（模板待定）一一详设阶段；产品设计原型一一详设阶段；产品使用说明书一一内测阶段.5. 1立项阶段流程立项阶段过程是产品的立项和设计过程.主体人员为公司高管和产品经理.立项 阶段过程主要是产品的规划、 方案过程,还包括一局部设计过程.规划和立项阶段本阶段的主要工作为对工程进行整体规划,并由相关人员进行风险评估,最后立 项,并初步确定工程
11、规模和分 配公司资源.这个阶段将产生3个工作成果：1. 总体规划文档这个文档描述产品主要概念，指出产品的关键特性和市场时.机，以及与众不 同的关键点,特性集和产品范 围.产品规划人完成产品描述后，由技术负责人进行技术风险评估，并在文档中描述技术规划和技术风险.2. 产品讨论会议总体规划文档产生后，产品经理召开产品讨论会议，参与人员包括公司高管、市场/销售、技术、治理/测试,大家通过产品经理或者筹划的讲解,对产品概念 进行了解和探讨,并将草案和构思形成产品雏形.3. 产品立项会议产品讨论会议完成后，决策层通过总体规划文档和相关会议了解产品前景和 风险,决定是否立项,如果立项,那么召开产品立项会议
12、,初步敲定工程规模并分 配公司资源.确认立项情况下,启动?立项工作单.doc?见附件2）2. 方案及设计阶段本阶段的工作目标主要集中在方案和设计上.本阶段将产生工程的整体方案,并 初步划分工程里程碑，同时, 各个生产部门完成生产所需设计文档.本阶段产生的工作成果如下：1 .方案U方案包括：a）产品筹划方案本方案即需求实施方案.方案为本阶段所有方案中最明确、最详细的计 戈限方案界定产品筹划工作 进度,从产品功能和设计层面拆分模块和险 峻段需求.方案结束后,整个工程的需求已经根本清楚.可 视为需求里程碑已到达.b）程序预研方案在筹划文档没有到位之前,程序研发方案可能是一个较为粗略的方案.但也可以对
13、技术摸索和前期技 术底层构架进行详细方案,如果工程经理 经验足够丰富，也可能根据经验提供一个较为详细的研发方 案.c）测试方案测试方案情况跟程序研发方案类似.d）市场/销售方案市场/销售方案可能需要跟产品筹划方案一同探讨制定.这个方案跟整个开发流程关联不大.e）工程综合方案综合方案由产品治理人员汇总所有的执行方案后决定.综合方案包含有 明确的工程里程碑日期，供高 层治理人员跟踪和掌控产品整体工作情况.2.产品设计文档产品实现方法的详细说明书，详细描述了这个产品的所有功能点.这份文档需要包括UI设计、可视化设 计图、核心运作机制、操作模式、操作流程、菜单 对话框，元素列表，可配置元素，产品原型等
14、等.这些文档将为程序制作和测试检验提供最重要的执行和检验依据.3 .技术设计文档.测试需求和测试用例根据产品定义测试需求,并制定相应的测试用例.5.2研发阶段流程研发阶段发生在立项阶段之后.主体人员为程序研发人员、产品经理及产品治理 人员.整个过程中主要是按产 品需求实施方案进行编码和测试验收模块的过程,还包括一局部评审和运营环节.1 .研发阶段研发阶段是技术部门对产品筹划的技术实现过程.参与人员主要为产品经理代表客户）和技术人员，研发阶 段工作成果如下：1 .程序研发方案细化；.产品模块的迭代开发方案的实施，这里需要把产品的每一个特性都分解为单独 的任务，尽可能的使任务细化. 并在研发过程中
15、积极参与,从产品角度及时的响应和限制变更.2 .验收阶段Pre-Alpha 版本这个版本是一个主体核心功能已经实现了的版本,并且已经整合了美术制作成果.版本目的是为了让决 策层、产品经理能够产生对产品的第一印象.第一印象的目的是评审产品的核心体验，以及确定筹划、美术 和技术实现的生命力.在这个版本过后,通常有一些产品元素需要重新设计和优化以改善产品质量.在产品验收阶段产品治理部测试专员负责功能测试.在产品验收阶段,单元测试/集成测试/性能测试由 技术负责.其他相关由产品经理负责.3 .内测阶段内测阶段在Alpha版本发布后开始.Alpha阶段的产生工作成果如下：1 . Alpha 版本Alph
16、a版本标志着所有产品特性已经完成，但通常会在具体的操作应用的友 好性易用性上有所欠 缺.Alpha版本的发布由产品经理、产品治理和技术人员共同决定.这个版本将提交产品部门进行优化.优化工 作包括对这个版本进行初始 的整体的平衡性调整以及细节的操作流程最优化.如果产品质量达不到设计的 质量标准或者产品标准，可能会对产品机制作较大的重新设计.2 .代码评审工作技术在Alpha这个阶段开始进行代码评审.代码评审由一组高级程序员进行.如果没有这么多高级程序 员，那么由程序员团队内部互审.评审工作通常包括设计模式、数据结构、程序健壮性、代码风格等方面.评审 者各自花1个工作日左右的时间来逐行检查代码，然
17、后集中讨论提供反响意见.4.公测阶段公测阶段在Beta版本发布后开始.Beta阶段产生的工作成果如下：1. Beta版本产品的Beta版本已经没有较大的Bug,所有产品特性和元素在这个版本 都已经完成.由运营部门对 这个版本的产品做最后的使用验收，以发现遗留问题.2.公测公测需求由产品经理和市场部门提出，由运维部门实施.为了配合市场运营，并且进一步开掘遗留问 题.Beta阶段通常将安排对产品的公测.4.发布阶段发布阶段研发已经根本完成.经过Release阶段后,研发工作全部结束,后续工 作交由运营部门负责.技术部 在获得?立项工作单doc?上的签署确认发布后安排产品上线.Release阶段工作
18、成果如下：1 .代码冻结.产品发布将产品发布到产品环境中.至此,这个研发过程结束.后续工作将由运营部接管.针对已发布的产品发起修 改需求仅重复研发阶段流程，由产品经理发起，填写工单和提交详细修改筹划启动流程.6 .需求变更流程面向不同对象的需求变更主要分为两种：对原有需求的变更；在原有需求根底上产生新需求.对任意工程及产品或事件的变更流程可参考事件治理流程,根据不同的变更需求酌 情处理,主要如下：1 .填写？需求变更工作单.doc?递交产品治理部，如产品经理在收到需求变更人递交 的申请后自判断事件较小且已 事先沟通,或紧急需求,可通过邮件形式发送技术总 监/产品总监,确认后马上进入研发流程,事
19、后补填工作单；2 .产品治理部对需求变更引起的影响进行分析,如属高危需求,立即通知受影响部门，得到确认后递交技术部；3 .技术部获得明确的需求变更后,反响评估意见,产品治理部进行跟踪.7 .附录文档命名规那么标准文档命名是为了便于对工程及公司内部文档进行治理和维护.工程文档：文档主题（版本）一部门姓名一日期如：产品筹划筹划部门.常智山说明：1 .文档主题一一当前文档内容，如页面筹划，市场调研，工作方案，会议纪要、等，可附加版本，如,.仅对其中 部份内容进行修改可升级小版本号，阶段成果可 升级大版本号.2 .部门一一所属部门，如产品部.姓名一一提交文档人姓名3 .日期yyyynmidd, YYY
20、Y为年，如2002 mm为月，如08 （缺乏两位的前面补零）， dd为日，同足两位前面补零.部门文档：文档主题（版本）一部门日期如：文档命名标准一产品部一附件一：事件工作单附件二：立项工作单附件三：需求变更工作单事件工作单提交日期期望完成日期事件阐述事件描述重要性高口中口低紧急性高口中口低需求发起人所属部门产品经理主管签章工作实施方案及审批工作量人/日预计开始开发时间预期完成时间风险度低口中口高评估意见评估人签字：是否需提交原型口需要口不需要指派技术负责人参与开发人员技术总监签字产品总监签字工作暂停/取消一恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品治理签字恢复时间产品总监签字技术总监签字产品治理签字工作完毕审核是否延期口是口否原因：实际完成时间产品治理签字是否发布口同意不同意产品经理签字产品总监签字技术总监签字备注：事件相关物料规划文档是否提交口功能规格说明书是否提交口需求分析说明书是否提交口产品设计原型是否提交口产品使用说明书是否提交口