没有流程规范就没有管理，感觉是随意带来高效，往往是随意带来的是混乱，熵增定律是不能违背的，面对复杂纷繁的事和人，是需要规范流程和制度来协作和串联的！
今天就给大家分享一个《项目管理规范标准流程V3.0》实例，供大家参考；
一、 规范背景
1) 目的
²为了适应公司的发展，对项目管理流程进行修改和完善；
²规范项目管理流程，指导项目各成员更好的完成项目；
²通过实施有效的项目流程，满足在以下三方面项目管理有所进步：
n产品满足需求
n质量符合预期；
n项目时间符合计划
²通过对需求、计划、设计、开发、测试、发布、维护的全程控制，减少项目风险。
²规范的流程是一笔可以积累的财富，可以不断的提升我司项目管理的能力
2) 适用范围
公司常规涉及的所有项目和项目集；
3) 术语定义
|
术语 | 定义 |
PM | Project Manager, 项目经理 |
DCC | Document Control Center文档管理控制中心 |
QA | Quality Assurance品质保证 |
TDT | Technology Development Team 技术开发团队 |
UED | User Experience Design 用户体验设计 |
二、 项目管理流程图
说明：
1、整个项目不限于本流程中所规定的。
2、本流程仅对关键点进行了规定，可以灵活安排项目中的事项。
3、项目过程中提倡会下沟通确定相应问题，尽力减少涉及人数较多的大型会议。
4、项目过程中出现任何问题请及时暴露出来，以便及时推进解决。
5、产品需求不涉及的环节和DCC沟通后可以不提供相应文档。
三、 项目文档简介
注：
1.项目经理不明确指定则由产品经理担任。
2.特殊情况某些文档不需要编写时请和DCC人员确认。
3.变更申请和问题处理报告不发生则不必提交。
四、 项目阶段划分
|
阶段 | 参与角色 | 内容 |
需求阶段 | 产品经理 | 收集新项目需求、用户反馈、市场和商务反馈、竞品研究、运营需求、内部系统优化等多方需求信息。并初步形成《需求设计说明书》。 《需求设计说明书》初稿可将需求分为功能需求、性能需求、数据需求等，并注明需求优先级。 |
产品经理 项目经理 | 综合各方面信息和《需求设计说明书》，初步确定项目目标、项目重点等，找准项目定位，并初步规划时间。 | |
产品项目 UED 开发人员 | 开发人员根据《需求设计说明书》初稿和产品/项目经理进行初步技术可行性分析，确定哪些需可以实现，哪些需求不能实现，哪些需要讨论等，并初步对需求进行筛选。 | |
产品经理 项目经理 UED 客户端主管 服务端主管 测试主管 运营主管 数据主管 相关人员 | 1. 产品经理会前下发《需求设计说明书》初稿文档，并确认每一位评审者都收到需求文档，并且理解了评审要求（强烈建议当面沟通）。 2. 参与评审者应在会前整理问题清单。 3. 产品经理组织需求评审，对《需求设计说明书》初稿进行评审，项目经理、研发、测试、配置管理等人员参与，并提出意见，产品经理汇总所有评审意见并形成《需求评审记录》邮件，会后将评审结果及文档发布给相关人员 4. 产品经理根据评审意见组织相关人员修正《需求设计说明书》，如有需要，需再次评审。 5. 产品经理形成正式的《需求设计说明书》。 6. UED根据正式的《需求设计说明书》进行交互设计并完成《交互设计说明书》。 7. 会议上需和各部门主管确定项目各个环节的实际负责人。 | |
立项阶段 | 项目组成员 DCC 相关领导 | 1. 项目经理根据需求分别和客户端、服务端、测试、数据、运营等负责人沟通初步确定项目的时间后初步制定《立项报告书》初稿（必须包含项目计划，注明项目里程碑时点，确定项目组成员和定义好相关工作）； 2. 立项会议，项目经理和项目成员介绍项目的大体情况，项目的大体阶段划分，每个负责人所需要承担的大体任务，确定后续项目管理运作办法（项目日报、项目周会等）等，并评审《立项报告书》，经项目组成员、管理层评审通过后，上述文档作为公司和项目组关于项目目标和约束条件达成共识的实施文件而正式生效。同时为后续制定各个详细开发和测试计划做下铺垫。 3. 项目经理根据会议评审结果对《立项报告书》进行修改，然后发送给所有相关人员。 4. 《立项报告书》评审通过后，客户端、服务器、测试、数据等的负责人根据项目的整体进度制定相应的开发和测试计划。 |
设计阶段 | 服务端负责人 客户端负责人 数据端负责人 | 1. 研发负责人根据《需求说明书》和《立项报告书》确定详细的《开发计划》。 2. 研发负责人根据《需求说明书》编写《设计说明书》。 3. 研发负责人组织相关人员参加《开发计划》和《设计说明书》的评审工作。 |
测试负责人 | 1. 测试负责人根据《需求设计说明书》、《立项报告书》编写《测试计划》和《测试用例》。 2. 测试负责人组织相关人员评审测试计划和测试用例，会后发布会议记录。 3. 评审完毕后根据会议讨论内容对测试计划和用例进行修改完善，修改完成后发给相关人员。 注意：测试用例编写、评审部分可贯穿设计、开发两个阶段 | |
开发阶段 | 研发人员 产品经理 | 1. 研发人员进行代码编写，调试。 2. 研发人员进行功能自测试。 3. 开发过程中，如《需求设计说明书》和《交互设计》有更新，请及时通知相关人员并提交最新需求说明书文档给DCC。 4. 研发人员更新代码到指定位置，根据需要提交编译后版本，在测试管理系统上建立相关的版本并存放在规定的FTP对于项目的目录下。 5. 研发人员提交测试任务，并邮件通知相关人员，版本邮件发送请按照相关标准发送。 |
测试阶段 | 测试负责人 客户端负责人 服务端负责人 数据负责人 项目经理 产品经理 | 1. 测试人员检查研发人员提交的测试任务是否满足测试条件，如果不满足可以拒绝测试，并填写拒绝测试的原因。 2. 测试人员接受该测试任务后，按照《测试计划》组织相关人员，对项目进行测试，对于有性能测试要求的项目需进行性能测试。 3. 测试负责人对测试中发现的Bug上报Bug管理系统，并把测试报告发给相关人员。 4. 研发人员修改Bug，并重新提交测试版本。 5. 服务端负责人提交《上线部署方案》，相关管理者对此进行审批。 6. 部署人员审核部署工单，并参考《上线部署方案》进行系统上线部署。 7. 部署完成后测试人员对线上系统进行测试验证，如有问题提交到管理系统。 8. 数据分析人员确定数据需求已经完成并正常可用。 9. 最后一个测试版本结束后，项目经理组织会议评审遗留bug，测试结果是否满足发版条件等。 10. 项目经理和所有相关方确认各环节情况是否具备发布条件。 |
发布阶段 | 项目组成员 商务人员 相关领导 | 1. 项目经理预先评估提交的版本是否满足发布标准，如果满足则进行下一步。 2. 项目经理协助检查项目中各个文档是否按规定提交，DCC人员发版前检查各项文档是否齐全规范。 3. 项目经理组织版本发布评审，根据公司版本发布判定标准，进行版本发布判定。各负责人对负责项进行检查，最后完成《版本发布评审记录》。 4. 客户端负责人确定最终版本，并对最终版本进行封版，发布流程完成后项目经理协调开发人员生成各个渠道版本，并提交测试验证。 5. 产品经理提供《产品手册（包含客服文档）》给项目组成员、客服人员和DCC。 6. 产品经理通知客服及相关部门版本发布的信息。 7. 项目经理协助商务人员对版本进行发布。 |
维护阶段 | 运营负责人 研发负责人 项目经理 | 1. 运营、市场、客服或者数据部门收集问题或投诉，并将问题和结果反馈给项目经理。 2. 项目经理安排测试和研发人员进行问题重现。 3. 研发人员对问题类型评估（拒绝问题或者解决问题），进行缺陷修正和故障处理支持。 4. 项目经理汇总Bug数据和重点问题，并分析原因。 5. 问题处理完成，项目经理组织开发、测试和其他人员完成问题处理报告。 6. 运营人员在一定时间内提供运营报告给项目组和相关人员。 7. 当项目正式运营后，项目经理编写项目总结报告，并召开项目总结会议（小项目可省略会议）。 8. DCC检查： 1) 检查关键文档的输出和存档。 2) 发布检查报告（按月发布，管理层审核）。 |
五、 变更管理流程
说明：需求变更涉及关键路径时请遵守此流程，请更新《需求设计说明书》、《交互设计说明书》、并通知项目组所有成员和相应主管，涉及到代码改动和用例改动的还需要重新进行开发时间评估，完成后遵照项目管理流程进行。
六、 项目管理制度
1.产品和设计文档、技术文档需要同步，开发人员根据文档进行软件设计，测试人员根据文档进行软件设计；
2.所有项目变更需要通知项目组所有成员以及相关主管；
3.项目开发过程中任何可能影响到项目进度的问题，需要主动告知项目经理协调解决；
4.项目组成员以及成员项目角色的变更需要及时通知项目组成员，相关部门负责人有且仅有一个。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
