Ultimate Project – The Ultimate Tool for PM 项目管理计划
一、变更管理计划
描述在整个项目期间如何正式审批和采纳变更请求。
变更常见原因
1、产品范围定义过失或疏忽；2、项目范围定义过失或疏忽；3、增值变更；4、对风险的应急计划或回避计划；5、项目执行过程与基准要求不一致带来的被动调整；6、外部事件。
项目经理在变更中的作用
响应变更提出者的要求，评估变更对项目的影响及应对方案，将需求由技术需求转化为资源需求，供授权人决策；根据评审结果实施即调整基准。确保项目基准反映项目实施情况。
变更工作程序
-
1、提出与接受变更申请；
-
2、对变更初审（施加影响，确定必要性；格式效验、完整性效验、确保准备充分；在干系人间就评估的变更信息达成共识。），常见方式是变更申请文档的审核流转。
-
3、变更方案论证；
-
4、项目管理委员会（CCB）审查；
-
5、发出变更通知并组织实施；
-
6、变更实施的监控；
-
7、变更效果评估（首要的评估依据是项目基准；结合变更初衷，看变更所要达到的目的是否达成；评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决）；
-
8、判断变更后的项目是否已纳入正常轨道。
变更控制流程
1、提出变更申请；2、对变更分析评估；3、CCB审核变更；4、批准变更；5、实施变更；6、验证变更；7、变更信息归档。
变更管理主要任务
1、分析变更必要性和合理性，确定是否实施变更；2、记录变更信息，填写变更控制单；3、做出更改、并交上级（CCB）审批；4、（实施变更）修改相应的软件配置（基线），确立新版本；5、评审后发布新版本（结束变更）
二、配置管理计划
描述如何记录和更新项目的特定信息，以及应当记录和更新哪些信息，以保持产品、服务或成果的一致性和（或）有效性。
文件变更记录：
| 版本号 | 编写日期 | 编写人 | 变更内容 |
|---|---|---|---|
| V1.0.0 | 2020.06.16 | Million Benjamin | 项目章程 |
| V1.0.1 | 2020.06.20 | Wendy | 配置管理计划 |
项目角色及职责：
| 昵称 | 岗位角色 | 分工内容 |
|---|---|---|
| Million Benjamin | 项目负责人、Python工程师 | 使用Flask/Django框架进行后端搭建 |
| shane | 项目经理或者客户经理 | 分解需求和做PPT |
| Alex | 产品经理，UI/UX设计师 | 前端开发，产品规划 |
| Steve | 产品经理，DevOps工程师 | 需求说明，运营反馈 |
| Wendy | 客户经理 | 需求调研等 |
| Aivo | 产品经理，数据库DBA | 后台开发 |
| carroll | js工程师 | 前端开发 |
| Prince Bear | 项目经理，Java工程师 | 移动端开发（Android） |
| TD Wen | 数据库DBA | 数据库管理监控升级调优等及后台开发 |
| George Wang | 客户经理、数据库DBA | 客户经理：客户访问&需求调查、客户分析与分类or数据库DBA：设计、安装、监控数据库 |
| Spike | UI/UX设计师 | 更喜欢搞UI这些 |
| Axing | 产品经理 | 线框图，原型设计 |
| Jim Chan | 客户经理，产品经理 | 因为代码能力非常非常薄弱，可能只能负责一些管理岗位，或者优化界面一类的工作 |
配置库目录：
- 1、About（项目概况）
- 2、Team profile（团队组建与分工）
- 3、Investigation（项目前期调研/竞品分析）
- 4、Vision（项目愿景）
- 5、Product Backlog （产品特性库）
- 6、Requirement specification（需求规格说明书）
- 6.1 Usecase Diagram and UML Activity Diagram（用例图，业务过程/多泳道图）
- 6.2 Use Cases（用例+活动图）
- 6.3 Domian Models（领域模型）
- 6.4 State Models（状态模型）
- 6.5 System Sequence Diagrams（功能模型）
- 6.6 Supplementary Requirements（补充需求）
- 7、Design（设计说明书）
- 7.1 UI design（界面设计）
- 7.2 Database design（数据库设计）
- 7.3 Interface API design（接口 API 设计）
- 7.4 Architecture design（架构设计）
- 7.5 Usecase design（用例设计）
- 8、生产规范与指南
- 8.1 XX 代码规范
- 8.2 REST API 设计规范
- 8.3 架构设计、详细设计（BCE方法）到应用程序框架映射指南
- 8.4 部署说明
- 9、成品展示
- 9.1 XX短视频
- 9.2 XX短视频
- X1 meeting-records
- inception meeting (yy/mm/dd)
- X2 KANBAN
- X3 auditing-records
- X4 Tech/Work Report
- 学号-title
- X5 Final Report
- 学号-title
- 小组分工与贡献率说明
基线配置：
| 基线名称 | 编号 | 配置项名称 | 负责人 | 计划提交时间 | 实际提交时间 | 备注 |
|---|---|---|---|---|---|---|
| 策划基线 | 1 | 项目章程 | Million Benjamin | 2020.06.23 | 2020.06.16 | - |
| 2 | 变更管理计划 | Alex | 2020.06.23 | 2020.06.23 | - | |
| 3 | 配置管理计划 | Wendy | 2020.06.23 | 2020.06.20 | - | |
| 4 | 绩效测量标准 | (黄冠纶) | 2020.06.23 | |||
| 5 | 项目生命周期 | (陈剑锋) | 2020.06.23 | 2020.06.23 | - | |
| 6 | 开发方法 | (王子豪) | 2020.06.23 | |||
| 7 | 管理审查 | (王子雄) | 2020.06.23 | |||
| 需求基线 | 8 | 初步需求文档 | (王思博、吴明章) | 2020.06.23 | ||
| 9 | 需求收集方法 | (温卓沛、幸赟、王嘉浚、顾子杉) | 2020.06.23 | |||
| 10 | 用户需求说明书 | |||||
| 11 | 软件规格说明书 | |||||
| 设计基线 | 12 | 概要结构设计说明书 | ||||
| 13 | 详细设计说明书 | |||||
| 编码基线 | 14 | 源代码 | ||||
| 15 | 可执行文件 | |||||
| 16 | 开发阶段测试用例 | |||||
| 17 | 测试计划 | |||||
| 18 | 用户手册 | |||||
| 测试基线 | 19 | 测试用例 | ||||
| 20 | 测试分析报告 | |||||
| 21 | 项目开发总结报告 |
三、绩效测量基准
经过整合的项目范围、进度和成本计划，用作项目执行的比较依据，以测量和管理项目绩效。
1. 项目范围：
- 协作沟通功能范围：小组会议、论坛交流
- 项目计划管理功能范围：看板、蓝图、任务分配、工时管理、Bug管理
- 项目报表功能范围：思维导图、在线文档、仪表盘
- 构建交付功能范围：DevOps
- 新增功能范围：网盘管理、公告管理、投票、软件测试
2. 进度计划：
- 第一阶段：6月1日项目正式开始前，组建项目团队，团队应包括管理岗人才、技术岗人才和质量岗人才，其中技术岗人才可以兼任其他两种类型的人才。同时还要确认外部顾问人选，可以是学院老师、企业从业人员。
- 第二阶段：6月15日前，总结现有项目管理软件的主流功能，并在团队内部头脑风暴讨论出至少三个可以额外添加的、能提升项目管理效率的功能组件，总结成需求文档。
- 第三阶段：8月15日前，完成初版应用（软件原型）开发，经过质量岗测试后，交由团队内部的管理岗进行使用体验，内部总结出改进方案。
- 第四阶段：9月1日前，根据内部总结的方案对初版应用进行改进，9月1日发布第一个正式版本供用户使用。
- 第五阶段：11月15日前，对第一版软件用户进行问卷调查，根据用户的体验情况，以及用户期望的新功能，对软件进行迭代改良。11月15日发布第二个正式版本供用户使用，而后进入长期迭代过程。
3. 成本计划： 该项目预算为80万元人民币，可能会根据需要增资。项目主要成本为内部开发团队和外部顾问的人工费用。服务器、开发用计算机等硬件以及网络服务优先使用学院现有的设备与服务，但仍有可能需要额外购买设备或服务。 | 阶段数 | 时间范围 | 预计成本 | 使用原因 | |——————– |—————————- |—————————- |———————————————————————————————- | | 1 | 2020.06.01前 | 20万 | 组建项目团队，聘请外部顾问 | | 2 | 2020.06.01-2020.06.15 | 5万| 内部开发团队工作开销 | |3|2020.06.15-2020.08.15|10万|内部开发团队工作开销，开发环境开销| |4|2020.08.15-2020.09.01|10万|内部开发团队工作开销，开发环境开销| |5|2020.09.01-2020.11.15|35万|问卷宣传费，内部开发团队工作开销，开发环境开销|
四、项目生命周期
描述项目从开始到结束所经历的一系列阶段。
1.规划阶段：
-需求分析
-目标
-范围
-轮廓
-要求
-可行性分析
-预期结果
2.计划阶段
-计划与预算
-进度计划
-任命
-建立组织
-责任分派
-启动
3.实施阶段
-工程实施
-活动协调
-进度控制
-预算控制
-阶段评审
-下马决策
-修订计划
4.完成阶段
-竣工
-文件整理
-验收
-移交
-解散组织
五、开发方法
描述产品、服务或成果的开发方法，例如预测、迭代、敏捷或混合型模式。
基于现有框架Vue或React中的一种，使用iview或antd库，构建前端Web交互界面。
对于已收集的需求（小组会议、论坛交流、看板、蓝图、任务分配、工时管理、Bug管理、思维导图等等），认为有必要挑选2~3个具体实现，个人倾向于任务分配、看板、论坛交流等。
架构暂定为基于Webpack打包的spa应用，不考虑后续封装库的模块化，所以不准备使用Rollup。
因为是实验性质的项目，不具备后续维护的价值，所以不准备引入单元测试和集成测试，但是会在Vue构建的基础上引入Jest和e2e，为后续可能的epc规范化留有余地。
虽然目前希望只实现以上提到的几个功能，但不排除之后会议决定扩展的可能，所以考虑在后端nginx支持基础上的多页面应用以及docker支持基础上的资源环境容器化，还有rpc或protoBuff支持基础上的微服务架构。因为项目不对外开放，不做分布式（k8s等）的考虑，预计没有serverless需求。
项目成果验收应该以产品提供的交互单为准，将依照原型实现界面以及交互。内部逻辑即数据流动可视情况自行决定。
作为一个toB的Saas项目，按照市场规范应该采用迭代式开发，并且辅以健全的测试、运维、重构。但是同样考录到这是一个不成熟的实验性质项目，将主要考虑采用敏捷式开发。
六、管理审查
确定项目经理和有关相关方审查项目进展的时间点，以考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施。
项目审查表：
| 审查时间 | 审查事项 | 应急预案 |
|---|---|---|
| 6月1日 | 确认团队成员是否到齐 | 技术岗人才可以兼任管理岗和质量岗工作 |
| 6月15日 | 完成需求文档 | 召开团队紧急会议，讨论出项目需求 |
| 8月15日 | 完成初版应用开发，经测试后总结改进方案 | 团队成员加班完成进度 |
| 9月1日 | 向用户发布第一个正式版本 | 对用户宣布产品跳票，团队成员加班完成进度 |
| 11月15日 | 向用户发布第二个正式版本 | 产品更新延后，团队成员加班完成进度 |