项目管理流程及规范.docx

1、 项目管理流程及规范2016 年 11 月 09 日2 / 8目录1. 文档目的 .32. 项目流程 .43. 项目流程规范 .53.1 需求（调研）分析 .53.2 产品低保真原型 .53.2 原型/需求 评审 .53.3 项目立项 .53.4 需求确认 .63.5 项目周期重新估算 .63.6 活动( 功能)时间估算 .63.7 需求变更管理 .73.8 风险预警 .73.9 进度控制 .73.10 质量管理 .83.11 产品发布 .83.12 项目验收 .83 / 81.文档目的本文档是为了解决公司人员对项目流程不清晰的问题，特别是项目组成员，项目经理、产品经理和各部门之间的协作，达到

2、合理管控项目，有制度可依。从而杜绝或减少项目排期混乱、随意插队等现象。4 / 82.项目流程5 / 83.项目流程规范3.1 需求（调研）分析1、 明确项目范围2、 明确项目目标3、 识别项目干系人并管理期望4、 整理项目需求5、 可行性分析（技术、经济、操作）6、 预测项目风险7、 以上内容形成项目概况报告，并包含初步的里程碑点和排期表8、 （外部如有需要可以实地考察，调研，需准备调研表格，做完后签字）9、 （如有方案或合同，项目经理需要仔细逐条过一遍，找出和实际的差异，内容形成差异报告含在项目概况报告里面）3.2 产品低保真原型1、 交付产品经理项目概况报告，项目和产品、需求方开会讨论需求

3、2、 产品出完整的低保真原型3、 项目经理需要对原型做检查，确保达到需求要求3.2 原型/需求 评审1、提前一天通知相关人员（项目、产品、前端、研发、业务、测试、运维）进行原型评审会议2、新的比较大的功能改动需要单独开展，小的需求和已有的小改动的评审可以含在立项会上开展3、会议上所有人需要发表对原型的看法，业务和项目要注意原型是否真满足了需求4、会议需要得出明确的结论，结束后形成会议纪要3.3 项目立项1、 邮件提前通知参会人员，包含业务、项目、产品、设计、前端、后端人员。邮件中需要包含明确的会议时间点，参会人员，会议预计持续时间、会议主题等要素。2、 会议立项1) 任命项目经理，组成项目团队

4、2) 项目经理主持会议，先介绍项目概况，展示项目概况报告；3) 项目经理讲解原型，讲解具体需求，细节由对应产品补充说明；项目不清楚时可由6 / 8产品来讲解原型，项目经理做补充。4) 需求讲完后讨论问题点，所有人发表看法，记录难点和问题点；5) 项目经理分解任务至各个部门人员，明确任务和责任，需对每个相关人做工时确认，并做排期确认。可根据项目概况报告里的初步排期表做确认。6) 明确项目沟通机制：技术碰到原型问题找产品，产品修改后通知项目，项目看过没问题产品再通知技术；项目需要的资料找项目；资源协调找项目；重要的问题出现找项目；项目和客户沟通；项目沟通障碍找业务帮助。重大问题开讨论会议解决。7)

5、 明确责任机制：项目经理拥有调动项目组资源的权利，对整个项目负主要责任；项目组成员每天需要把工作完成情况提交给项目经理；未完成本日任务不得擅自离开，如果有事必须先和项目经理沟通；任务未在规定时间内完成，开发者也需要承担责任；8) 会议结束，会议主持者或指定人员给参会人员发会议纪要3.4 需求确认1、 根据所获取的需求，写出简易版的需求功能点确认表，给客户签字确认2、 上一步操作受阻时，进一步和客户沟通，了解需求，变更需求。大多数客户需要视觉确认，这就需要做设计稿，在需求沟通清楚后安排设计稿开发（需要了解客户的喜好、当地的特色、主体基调和客户满意的图片或案例） 。3、 制作高保真原型4、 高保真

6、原型评审（至少需要产品、项目、设计参与） ，通过后把原型发给客户确认5、 重复 2-4 步骤，直至确认定稿（中间如有困难，找相应业务寻求协助） ，填写最终版需求确认书给客户，确认完后开始研发流程3.5 项目周期重新估算1、 根据需求确认的功能和确认的时间，对项目重新做时间估算，对比之前立项时的时间点，分析延误时间和补救措施2、 形成新的项目计划表，如果最终交付点变更，需要评审。找业务及相关人会议讨论，提交延误分析，会议讨论是否按原工期完成，如果按原工期改如何调整资源配置；如果同意延期，业务需要和客户解释延误原因。如果业务不能说服客户，那就需要更加加急时间和工期，如有必要可以暂时暂停其他项目来获

7、取资源。3、 明确新的各个阶段的里程碑点3.6 活动(功能)时间估算1、 采用 PERT 进行项目进度的活动估算2、 需要提供每个活动（功能点）的乐观时间 a、最可能时间 m、悲观时间 b3、 算出每个活动的期望 ti=(ai+4mi+bi)/6 ，方差 i=(bi-ai)/6)7 / 84、 算出总期望 T=t i ，总方差 = i ，标准差 =5、 在正态分布中 代表标准差 , T 代表均值。x=T 即为图像的对称轴3 原则为数值分布在（T-, T+)中的概率为 0.6826数值分布在（T-2, T+2)中的概率为 0.9544数值分布在（T-3, T+3)中的概率为 0.9974假如项目

8、需要在 30 天内完成，完成概率为：Pt30=(30-T)/ )查正态分布表得概率(查法：比如 (0.52)，先从纵坐标找到 0.5，再去横坐标找到 0.02，交叉的值就是所要找的值，这个值为 0.6985)附件：正态分布表正 态 分 布 表 .png3.7 需求变更管理1、 明确项目边界和范围，对于超过范围的需求需要让客户提需求变更，变更内部评审，评审结果形成变更确认单给客户确认，告知变更后所造成的时间、进度、成本的改变。需求客户确认后，调整项目计划和进度表，通知相关人，无问题后执行。2、 项目开发过程中的大改动，也需要做需求变更操作，同上操作。3.8 风险预警1、 在需求确认时，客户不给于

9、确认答复，在 2 天以上的，属于延期风险，需要联系业务，尽快让客户给予回复（提供答复的时间点给对方） 。如业务沟通后还未有解决趋势，在1 天后邮件告知对方风险，要求对方在某个时间点内给予答复。2、 设计稿反复修改，修改 2 稿后还未有明确需求方向，属于设计风险。需要重新分析客户的需求，如无头绪，需要找相关人员开会探讨解决方案。3、 其他项目过程中影响到每个阶段的里程碑时间点的事件，都属于风险，需要做风险识别，提前做好准备，出现风险在每周的周报里体现，问题严重立刻上报给上级领导，组织会议解决此问题3.9 进度控制1、 根据立项所得的计划表，每天对每个功能进行完成时间点检查，贯彻进度计划的实施，明

10、确责任。特别需要检查里程碑点的时间。2、 抓住关键活动的进度，此项出问题将导致项目整体延期。3、 把握项目实际实施情况，合理调度工作，保证资源及时供应。4、 进度检查报告，在每周的周报里体现，每周项目经理吧对于的项目周报发给相应人员5、 进度偏差分析。在预计时间范围外的，需要及时发现问题进行调整，并更新项目计划8 / 8表。可以调整后续任务时间来满足项目整体时间不变。实际上很多情况下存在项目整体后延的情况，这时需要和客户沟通，征求客户意见。如果时间延误是客户造成的，适当延后时间是合理的，否则为满足需求需要增加资源或降低质量。3.10 质量管理1、 原型出来后，项目经理需要仔细检查，通过后执行下

11、一步原型评审2、 设计稿在出稿后，其领导、对应项目和产品需要做评审，不通过驳回继续修改3、 前端和后端功能完成后，及时交付测试，测试测出 BUG 修复，直至无问题3.11 产品发布1、 邮件通知相关人员留下等待发布和解决其中产生的问题2、 先在 alpha 上测试，通过后上线 RC3、 RC 上测试，通过后上线正式4、 正式上线后继续测试，无问题上线成功，相关人员撤离3.12 项目验收1、 在项目功能完成后，试用期结束时或即将结束时，向客户发起验收申请2、 需要准备验收报告、操作手册、历史变更申请记录、试运行报告等过程或阶段性文件3、 明确验收标准、验收时间、验收步骤和流程，处理好客户的关系4、 项目收尾，项目人员前往其他项目，通知业务合同收尾