还剩13页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
密级■保密□通用项目管理规范V
1.0版编写日期2009-2-5北京xxx科技有限公司地址北京市西城区xxx室邮编xxx电话010-xxxxx传真010-xxxxxxxx网址http://www.xxxxx.com目录TOC\o1-3\u目录31.文档版本控制
41.1文档说明
41.2文档更新纪录42.职能
52.1产品管理部
52.2需求管理员
52.3技术部/手机软件部
52.4需求提出人员53.需求判别流程54.工单管理流程65.产品制作流程75.1立项阶段流程85.2研发阶段流程106.需求变更流程137.附录137.1文档命名规则13附件一事件工作单14附件二立项工作单14附件三需求变更工作单141.文档版本控制
1.1文档说明本文档为金色经纬项目管理流程专用说明文档文档总括性的叙述了因需求可能产生的项目/事件的制作流程,以及各个阶段的划分方法和工作产物本文不包括产品开发过程中各个角色的工作流程,具体工作流程请参考各个部门的具体工作流程文档文档主要包括以下内容1.小型项目/事件管理流程;2.产品化项目管理流程;3.需求变更管理流程;
1.2文档更新纪录作者日期版本内容参与者备注罗心晶2009-2-5V
0.12.职能应当阅读此文档的人员为任何参与到产品开发过程中的角色,包括中高层管理人员(总监及高管)、产品策划人员、技术开发人员、运维人员、市场/销售人员重要角色包括产品管理部、需求管理员、产品经理(需求提出人)、技术人员其中对重要角色职能及相关要求定义如下
2.1产品管理部负责产品和项目开发规范的制订,并监督其执行情况
2.2需求管理员检查相关文件,签名是否齐备,落实阶段需求文档到位,向开发人员提交开发任务,负责将需求,项目状态更新到TD,ProjectServer中
2.3技术部/终端部所有开发需求必须经过产品管理部需求管理员同意,确认方可开始进行开发;发布人员必须经过需求管理员同意,确认签字方可发布程序
2.4需求提出人员工作量大于1人/天的任务,必须经过需求管理员同意,确认后方可提交给开发人员3.需求判别流程根据公司现阶段发展及实际工作情况,总结因需求可能产生的项目/事件,发起的过程相同,整理归纳大致流程如下其中关键部份为判断需求级别
①产品经理发起需求草案,并与技术部进行可行性分析和工作量预判工作,根据技术部提供的建议对方案进行调整;并根据调整后的需求草案发起讨论会议在会议上将确认该需求进入相应流程草案需求讨论会议为非常规流程,但判断需求级别最简要求CTO或COO签字或邮件确认;
②需求类型分两种需求变更——对已实施产品或项目进行变更需求;新需求——新需求根据工作量及重要性分为工单和项目两种流程;
③判断新需求级别工作量工作量大于3×1人/周工作量大于3×1人/日小于等于3×1人/周工作量小于等于3×1人/日分类项目项目工单说明现技术部分为两个工作组,一组5人,一组7人,工作量评估建议以重要性较高,且独立工作组一半人数以上/日列为项目
④进入工单管理流程——产品经理启动《事件工作单》,产品总监技术总监签字或回复邮件确认生效;
⑤进入产品化项目管理流程——产品经理启动《项目工作单》;
⑥进入需求变更管理流程——产品经理启动《需求工作单》4.工单管理流程经确认需求为工单,应进入如下流程产品经理需填写《事件工作单.doc》(见附件1),描述事件要点,并单独附事件详细设计文档,交由产品管理进行分析评估,如需求与事件工作描述差异较大,或事件工期超过3个工作日,将提交产品总监技术总监确认,明确开发要求及需求后,转交技术部相关负责人进行研发并跟踪进度如事由紧急,事件需求负责人可直接以邮件/文档等形式向产品总监技术总监确认,技术总监确认同时安排指定工程师,确认同时抄送产品管理组进行控制及跟踪进度启动工单流程后,在整个研发过程中状态如下进入暂停状态后,如需恢复,重新启用工单流程5.项目管理流程如判断某个草案将形成产品化项目,应按以下流程进行管理和控制除指定物料和里程碑,所有细节可由具体操作人自行把握,仅供参考项目管理流程将产品的制作过程分为两个部分立项阶段和开发阶段经过这两个过程后,产品将脱离制作流程,进入运营流程运营流程的具体情况请参阅运营流程文档为了更清晰的表达各个阶段的进行流程,给出一个整体示意图在每个阶段中,项目将分割为如下状态下面对于每一个过程,分别给出流程图,并对整个流程的概述流程中的每一个阶段,都将安排一个评审会议,在评审会议上,产品、技术、管理测试和市场/销售代表对相应的提交物进行评估和评论,其目的是在每一个阶段加强公司内部各个部门对产品整体质量、进度的了解和认识,并在下阶段优化和改进产品从另一方面说,如果项目进展或质量达不到要求的话,任何一个阶段评审会,都给高层管理一个终止项目,规避风险的机会在整个项目管理流程中,以下物料分别为各个阶段的必备文档,产品经理应严格遵从模板样式,按时提交规划文档(可为邮件,大纲等非正式文档)——规划阶段;功能规格说明书(模板待定)——概计阶段;需求分析说明书(模板待定)——详设阶段;产品设计原型——详设阶段;产品使用说明书——内测阶段5.1立项阶段流程立项阶段过程是产品的立项和设计过程主体人员为公司高管和产品经理立项阶段过程主要是产品的规划、计划过程,还包括一部分设计过程
1.规划和立项阶段本阶段的主要工作为对项目进行整体规划,并由相关人员进行风险评估,最后立项,并初步确定项目规模和分配公司资源这个阶段将产生3个工作成果1.总体规划文档这个文档描述产品主要概念,指出产品的关键特性和市场机会,以及与众不同的关键点,特性集和产品范围产品规划人完成产品描述后,由技术负责人进行技术风险评估,并在文档中描述技术规划和技术风险2.产品讨论会议总体规划文档产生后,产品经理召开产品讨论会议,参与人员包括公司高管、市场/销售、技术、管理/测试,大家通过产品经理或者策划的讲解,对产品概念进行了解和探讨,并将草案和构思形成产品雏形3.产品立项会议产品讨论会议完成后,决策层通过总体规划文档和相关会议了解产品前景和风险,决定是否立项,如果立项,则召开产品立项会议,初步敲定项目规模并分配公司资源确认立项情况下,启动《立项工作单.doc》(见附件2)
2.计划及设计阶段本阶段的工作目标主要集中在计划和设计上本阶段将产生项目的整体计划,并初步划分项目里程碑,同时,各个生产部门完成生产所需设计文档本阶段产生的工作成果如下1.计划计划包括a产品策划计划本计划即需求实施计划计划为本阶段所有计划中最明确、最详细的计划计划界定产品策划工作进度,从产品功能和设计层面拆分模块和险峻段需求计划结束后,整个项目的需求已经基本清晰可视为需求里程碑已到达b程序预研计划在策划文档没有到位之前,程序研发计划可能是一个较为粗略的计划但也可以对技术摸索和前期技术底层构架进行详细计划,如果项目经理经验足够丰富,也可能根据经验提供一个较为详细的研发计划c测试计划测试计划情况跟程序研发计划类似d市场/销售计划市场/销售计划可能需要跟产品策划计划一同探讨制定这个计划跟整个开发流程关联不大e项目综合计划综合计划由产品管理人员汇总所有的执行计划后决定综合计划包含有明确的项目里程碑日期,供高层管理人员跟踪和掌控产品整体工作情况2.产品设计文档产品实现方法的详细说明书,详细描述了这个产品的所有功能点这份文档需要包括UI设计、可视化设计图、核心运作机制、操作模式、操作流程、菜单/对话框,元素列表,可配置元素,产品原型等等这些文档将为程序制作和测试检验提供最重要的执行和检验依据3.技术设计文档4.测试需求和测试用例根据产品定义测试需求,并制定相应的测试用例5.2研发阶段流程研发阶段发生在立项阶段之后主体人员为程序研发人员、产品经理及产品管理人员整个过程中主要是按产品需求实施计划进行编码和测试验收模块的过程,还包括一部分评审和运营环节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.需求变更流程面向不同对象的需求变更主要分为两种对原有需求的变更;在原有需求基础上产生新需求对任意项目及产品或事件的变更流程可参考事件管理流程,根据不同的变更需求酌情处理,主要如下1.填写《需求变更工作单.doc》递交产品管理部,如产品经理在收到需求变更人递交的申请后自判断事件较小且已事先沟通,或紧急需求,可通过邮件形式发送技术总监/产品总监,确认后马上进入研发流程,事后补填工作单;2.产品管理部对需求变更引起的影响进行分析,如属高危需求,立即通知受影响部门,得到确认后递交技术部;3.技术部获得明确的需求变更后,反馈评估意见,产品管理部进行跟踪7.附录7.1文档命名规则规范文档命名是为了便于对项目及公司内部文档进行管理和维护项目文档文档主题(版本)_部门_姓名_日期如产品策划v
0.2_策划部门_常智山_20090205说明
1.文档主题——当前文档内容,如页面策划,市场调研,工作计划,会议纪要、等,可附加版本,如v
0.1,v
0.2v
1.0仅对其中部份内容进行修改可升级小版本号,阶段成果可升级大版本号
2.部门——所属部门,如产品部
3.姓名——提交文档人姓名
4.日期——yyyymmdd,YYYY为年,如2002,mm为月,如08(不足两位的前面补零),dd为日,同足两位前面补零部门文档文档主题(版本)_部门_日期如文档命名规范_产品部_20070523附件一事件工作单附件二立项工作单附件三需求变更工作单[ ]事件工作单提交日期期望完成日期事件阐述事件描述重要性□高□中□低紧急性□高□中□低需求发起人所属部门产品经理主管签章工作实施计划及审批工作量人/日预计开始开发时间预期完成时间风险度□低□中□高评估意见评估人签字是否需提交原型□需要□不需要指派技术负责人参与开发人员技术总监签字产品总监签字工作暂停/取消—恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品管理签字恢复时间产品总监签字技术总监签字产品管理签字工作完毕审核是否延期□是□否原因实际完成时间产品管理签字是否发布□同意□不同意产品经理签字产品总监签字技术总监签字备注事件相关物料规划文档是否提交□功能规格说明书是否提交□需求分析说明书是否提交□产品设计原型是否提交□产品使用说明书是否提交□[ ]立项工作单提交日期期望完成日期项目阐述项目需求及设计重要性□高□中□低紧急性□高□中□低需求发起人产品经理所属部门主管签章项目实施评估及审批工作量人/日预期开始开发时间预期完成时间是否需要提交原型□需要□不需要项目风险度□低□中□高评估意见评估人签字参与开发人员技术总监签字产品总监签字CTO签字产品管理签字项目暂停/取消—恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品管理签字恢复时间产品总监签字技术总监签字产品管理签字项目完毕审核实际完成时间测试工程师签字是否延期□是□否原因是否发布□同意□不同意产品管理产品经理签字产品总监签字技术总监签字CTO签字备注项目相关物料规划文档是否提交□功能规格说明书是否提交□需求分析说明书是否提交□产品设计原型是否提交□产品使用说明书是否提交□需求变更工作单事件/项目名称需求编号需求修改原因提交日期期望完成日期修改类别□添加新需求□修改原需求重要性□高□中□低紧急性□高□中□低需求修改阐述需求修改描述需求提交人产品经理影响分析对原需求影响程度□高□中□低受影响部门受影响部门意见产品经理产品管理工作实施计划及审批工作量人/日开始开发时间预期完成时间风险度□低□中□高评估意见评估人签字是否需提交原型□需要□不需要指派技术负责人技术总监签字产品总监签字项目暂停/取消—恢复暂停/取消原因暂停/取消时间产品总监签字技术总监签字产品管理签字恢复时间产品总监签字技术总监签字产品管理签字工作完毕审核实际完成时间产品管理签字是否延期□是□否原因是否发布□同意□不同意产品经理签字产品总监签字技术总监签字立项阶段规划和立项计划和设计开发阶段研发阶段AlphaBetaRelease。