- 必要性
项目的范围管理一直是项目管理当中的一个痛点,特别是在对国内项目中,客户由于种种原因,在项目立项初期并没有对项目的整体情况进行全面综合的考量,甚至在提供了解决方案后也不会对提供的方案,功能清单的技术资料进行详细的解读,以至于在项目研发过程中客户随意随性的提出功能的增加、变更,发生严重的项目范围蔓延,随着带来了,在对目的进度、质量、成本造成连环影响。为了最大程度的防止范围蔓延的风险,拟制定了此管理办法。
- 范围掌控点
项目周期中,对项目范围进行掌控主要集中在两个地方。一是在项目立项时要明确需求功能范围,在一般项目中往往使用需求功能管理矩阵,对项目的整体功能需求进行描述,项目总共包括哪些功能模块,每个功能模块包括哪些功能页面及功能点..,另外一个是在项目研发过程中,用户提出的一些需求功能的变更,包括新增加的功能和进行变更的功能。这两个掌控点同时也是相辅相成的。也是构成整个项目范围边界管理的关键所在。
所以本管理办法对项目的需求范围分为两部分进行管理。
- 项目需求功能范围管理
- 项目需求变更管理
- 项目需求范围管理
1、阶段说明
目 的:对项目整体研发范围进行一个范围边界的划定
前置条件:签订商务合同前或项目进入研发阶段之前
后续事项:根据需求功能范围进入系统研发
产生文档:项目需求功能范围确认单
主要事件:前端支撑部门进行项目范围的梳理,形成文档
客户对项目需求功能范围确认单进行签字、确认
在项目需求功能范围确认过程,主要对以下项目范围进行明确。
- 应用平台种类(是包含PC和移动两种,还是只包含了PC端或是移动端应用)
- 系统功能清单(Web、App)
- 主要业务流程图
- 系统角色划分
- 系统权限划分(页面权限、数据权限)
- UI设计风格确认
- 培训方式(集中统一、各单位、无需培训)
- 其他需求
在进入研发阶段,按照事先签订的确认单进行项目的研发。
2、签署流程
3、需求功能范围确认单
项目需求、功能范围确认单
项目名称 | 前端支撑填写 |
| ||||
客户名称 | 前端支撑填写 |
| ||||
客户对接人 | 前端支撑填写 | 职务 | 前端支撑填写 | 联系电话 | 前端支撑填写 |
|
项目概述 | 前端支撑填写 |
| ||||
功能范围概述 | PC端:前端支撑填写 App端:前端支撑填写 |
| ||||
平台范围 | PC端 ☒ 移动端(App(安卓) ☐ App(IOS) ☐ 公众号 ☒) |
| ||||
使用范围 | 前端支撑填写 |
| ||||
数据范围 | 前端支撑填写 |
| ||||
其他确认项 | 业务流程图 ☒ UI设计风格☒ 业务角色 ☒ 数据权限 ☒ 页面权限 ☒ |
| ||||
需求功能清单 | PC端 ☒ 移动端( App(安卓) ☐ App(IOS) ☐ 公众号 ☒) |
| ||||
培训方式 | 集中统一 ☐ 逐个单位培训 ☐ 无需培训 ☐ |
| ||||
客户需求对人确认 |
|
| ||||
商务经理确认 |
|
| ||||
项目经理确认 |
|
|
附件一 业务流程图
附件二 功能需求范围清单
1、WEB端需求功能清单
“两个责任”云平台WEB端需求功能清单 | ||||
No. | 一级模块 | 二级模块 | 页面(功能)名称 | 功能概述 |
模块名称 | 模块名称 | |||
1 | 登录页 | 登录 | 登录 | ①采用分配好的账户名和密码登录该系统,系统不支持开放注册; |
系统公告 | 系统公告轮播 | ①以轮播图+文字的形式展示在登录页面,此部分面向公众开放; |
2、移动端需求功能清单
“两个责任”云平台移动端需求功能清单 | ||||
No. | 一级模块 | 二级模块 | 页面(功能)名称 | 功能概述 |
模块名称 | 模块名称 | |||
1 | 登录 | 登录 | 登录 | ①采用分配好的账户名和密码登录该系统,系统不支持开放注册; |
2 | 首页 | 落实责任 | 待办工作列表 | ①根据用户权限,显示该登录用户的待办任务; |
待办工作详情 | ①支持点击查看待办工作详情; | |||
历史责任 | 已办工作列表 | ①根据用户权限,显示该登录用户的已办任务; | ||
已办工作详情 | ①支持点击查看已办工作详情; | |||
信息修改 | 变更密码 | ①个人修改密码; |
3、其他需求功能清单
“两个责任”云平台其他需求功能清单 | ||||
No. | 一级模块 | 二级模块 | 页面(功能)名称 | 功能概述 |
模块名称 | 模块名称 | |||
1 | 短信接口 |
|
|
|
4、业务角色范围
“两个责任”云平台业务角色范围 | |||
No. | 角色名称 | 角色层级 | 角色应用范围 |
1 | 纪委(超级管理员) | 一级 | ①拥有系统最高管理权限; ②包含派单、督查、统计等; |
2 | 纪委各室 | 二级 | ①平台浏览权限; ②包含派单(临时性任务)、督查、统计等; |
3 | 各乡镇纪委、各派出纪检组 | 三级 | ①可针对市级及各单位办理情况进行抽查; ②无派单权限; ③拥有查看下属管辖范围内分数排名的权限; ④拥有更新、履责任务的权限; |
5、系统数据权限
组织架构或是角色中数据权限的划分规则进行说明。
6、系统页面权限
通过可配置实现角色到菜单是否具有可以查看权限,到页面具有(查看和编辑)权限。(不会具体到页面的功能按钮权限控制)
附件三 页面设计风格
PC端
1)登录页
- 需求变更申请
1、阶段说明
目 的:对项目研发过程中出现的需求变更进行管理、留痕
前置条件:签订需求范围确认单、进入研发阶段
后续事项:根据需求申请单,在工期,工数上的影响,是否进行应对
产生文档:需求变更申请单
主要事件:客户对项目需求变更申请单进行签字、确认
项目组对需求变更进行评估
提交商务进行谈判、决定
2、需求变更流程
3、功能需求变更申请表
功能需求变更申请表
项目等级分类: | A | ☐ | B | ☐ | C | ☐ | D | ☐ | |||||||||||||
项目编号 | 商务填写 | ||||||||||||||||||||
项目名称 | 商务填写 | ||||||||||||||||||||
客户名称 | 商务填写 | ||||||||||||||||||||
客户联系人 | 商务填写 | 联系邮箱 | 商务填写 | 联系电话 | 商务填写 | ||||||||||||||||
需求变更信息前端支撑填写 | |||||||||||||||||||||
需求提出人 | 前端支撑填写 | 职务 | 前端支撑填写 | ||||||||||||||||||
提出日期 | 前端支撑填写 | 要求完成日期 | 前端支撑填写 | ||||||||||||||||||
变更原因 | 前端支撑填写 | ||||||||||||||||||||
变更内容 前端填写 | |||||||||||||||||||||
No | 类型 | 变更内容 | |||||||||||||||||||
1 | ☐新增 ☐变更 | 变更前 |
| ||||||||||||||||||
变更后 |
| ||||||||||||||||||||
2 | ☐新增 ☐变更 | 变更前 |
| ||||||||||||||||||
变更后 |
| ||||||||||||||||||||
影响评估 | |||||||||||||||||||||
关联影响范围描述 | 研发部填写 | ||||||||||||||||||||
工数评估 | |||||||||||||||||||||
变更内容工数 | 研发部填写 | 人天 | 关联影响工数 | 研发部填写 | 人天 | ||||||||||||||||
客户方确认意见 |
| ||||||||||||||||||||
商务经理意见 |
签字: 年 月 日 | ||||||||||||||||||||
项目经理确认意见 |
| ||||||||||||||||||||
研发部审批意见 |
变更工数超过3天需要审批 | ||||||||||||||||||||
研发部审批意见 |
变更工数超过3天需要审批 | ||||||||||||||||||||
技术总监审批意见 |
变更工数超过3天需要审批 | ||||||||||||||||||||
销售副总审批意见 |
变更工数超过3天需要审批 | ||||||||||||||||||||
总经理审批意见 |
变更工数超过3天需要审批 |
- 审批方式
由于人员流动性,为了加快立项审批效率,建议先采钉钉的通用审批进行变更申请及审批(变更申请表作为附件)。审批完成后,由综合部门对立项材料进行纸质打印,由各环节负责人,签字存档。
No | 立项方式 | 发起者 | 第一审批 | 第二审批 | 第三审批 | 第四审批 | 抄送 |
1 | 变更申请 | 前端经理 | 销售副总 | 技术部负责人 | 研发部主管 | 总经理 |
|