产品项目管理规范.doc

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