产品项目管理规范.doc

. . 密 级：■ 保密 □ 通用 项目管理规范 V1.0版 编写日期：200 北京xxx科技有限公司 地址：北京市西城区xxx室 邮编：xxx 电话：010-xxxxx 传真：010-xxxxxxxx 网址： 目录 TOC \o 1-3 \u 目录 3 1．文档版本控制 4 1.1 文档说明 4 1.2 文档更新纪录 4 2．职能 5 2.1 产品管理部 5 2.2 需求管理员 5 2.3 技术部/手机软件部 5 2.4 需求提出人员 5 3．需求判别流程 5 4． 工单管理流程 6 5．产品制作流程 7 5．1 立项阶段流程 8 5．2 研发阶段流程 10 6．需求变更流程 13 7．附录 13 7．1 文档命名规则 13 附件一：事件工作单 14 附件二：立项工作单 14 附件三：需求变更工作单 14  1．文档版本控制 1.1 文档说明 本文档为金色经纬项目管理流程专用说明文档。文档总括性的叙述了因需求可能产生的项目/事件的制作流程，以及各个阶段的划分方法和工作产物。本文不包括产品开发过程中各个角色的工作流程，具体工作流程请参考各个部门的具体工作流程文档。 文档主要包括以下内容： 小型项目/事件管理流程； 产品化项目管理流程； 需求变更管理流程； 1.2 文档更新纪录 作者 日期 版本 内容 参与者 备注 罗心晶 200 V0.1 2．职能 应当阅读此文档的人员为任何参与到产品开发过程中的角色，包括： 中高层管理人员（总监及高管）、产品策划人员、技术开发人员、运维人员、市场/销售人员。 重要角色包括：产品管理部、需求管理员、产品经理（需求提出人）、技术人员。 其中对重要角色职能及相关要求定义如下： 2.1 产品管理部 负责产品和项目开发规范的制订，并监督其执行情况。 2.2 需求管理员 检查相关文件，签名是否齐备，落实阶段需求文档到位，向开发人员提交开发任务，负责将需求，项目状态更新到TD，Project Server中。 2.3 技术部/终端部 所有开发需求必须经过产品管理部需求管理员同意，确认方可开始进行开发； 发布人员必须经过需求管理员同意，确认签字方可发布程序。 2.4 需求提出人员 工作量大于1人/天的任务，必须经过需求管理员同意，确认后方可提交给开发人员。 3．需求判别流程 根据公司现阶段发展及实际工作情况，总结因需求可能产生的项目/事件，发起的过程相同，整理归纳大致流程如下： 其中关键部份为判断需求级别。 ① 产品经理发起需求草案，并与技术部进行可行性分析和工作量预判工作，根据技术部提供的建议对方案进行调整；并根据调整后的需求草案发起讨论会议。在会议上将确认该需求进入相应流程。草案需求讨论会议为非常规流程，但判断需求级别最简要求：CTO或COO签字或邮件确认； = 2 \* GB3 ② 需求类型分两种： 需求变更——对已实施产品或项目进行变更需求； 新需求——新需求根据工作量及重要性分为工单和项目两种流程； ③ 判断新需求级别 工作量 工作量 大于3×1人/周 工作量 大于3×1人/日 小于等于3×1人/周 工作量 小于等于 3×1人/日 分类 项目 项目 工单 说明：现技术部分为两个工作组，一组5人，一组7人，工作量评估建议以重要性较高，且独立工作组一半人数以上/日列为项目 ④ 进入工单管理流程——产品经理启动《事件工作单》，产品总监技术总监签字或回复邮件确认生效； = 5 \* GB3 ⑤ 进入产品化项目管理流程——产品经理启动《项目工作单》； = 6 \* GB3 ⑥ 进入需求变更管理流程——产品经理启动《需求工作单》。 4． 工单管理流程 经确认需求为工单，应进入如下流程： 产品经理需填写《事件工作单.doc》（见附件1），描述事件要点，并单独附事件详细设计文档，交由产品管理进行分析评估，如需求与事件工作描述差异较大，或事件工期超过3个工作日，将提交产品总监技术总监确认，明确开发要求及需求后，转交技术部相关负责人进行研发并跟踪进度。 如事由紧急，事件需求负责人可直接以邮件/文档等形式向产品总监技术总监确认，技术总监确认同时安排指定工程师，确认同时抄送产品管理组进行控制及跟踪进度。 启动工单流程后，在整个研发过程中状态如下： 进入暂停状态后，如需恢复，重新启用工单流程。 5．项目管理流程 如判断某个草案将形成产品化项目，应按以下流程进行管理和控制。除指定物料和里程碑，所有细节可由具体操作人自行把握，仅供参考。 项目管理流程将产品的制作过程分为两个部分：立项阶段和开发阶段。经过这两个过程后，产品将脱离制作流程，进入运营流程。运营流程的具体情况请参阅运营