目录

第一章 总则

1  目的

为了保护公司计算机信息系统安全，推进公司数字化转型建设，保证公司信息系统正常运行，加强产品、研发、测试、运维、项目管理等管理工作，提升工作效率以及各工作环节协同配合度，特制定本制度。

2  适用范围

本公司服务器、网络等基础设施，自研项目、实施项目等管理事宜均适用本制度。

第二章 业务需求管理制度

1 目的

为了规范需求管理的过程和活动、更加有效地利用信息技术部的技术资源，故对业务需求管理做出相关规定。

2 名词解释

业务需求：指业务部门或外部用户对现有正常使用的系统提出新的功能、报表要求；或者业务部门针对某项业务提出的新建系统需求。

3 规范及流程

在建项目实施过程中的业务需求由产品经理负责，项目经理协助；日常工作中出现的业务需求由申请人在钉钉上填写《信息化需求申请》，由产品经理负责追踪反馈。
自研与外采系统需求管理流程如下：

3.1 需求管理目标

确定各方干系人对需求的一致理解。
管理和控制新需求与需求变更。
从需求到最终产品进行双向跟踪，保持产品和活动与需求一致。

3.2 需求管理过程

需求的来源是受控的，不能随便将需求纳入项目开发计划中，要经过受影响各方评审和同意。
项目计划、活动和工作产品都必须与需求保持一致。
对需求的实施过程进行监控，确保需求正确实现。
在需求发生变化时，要对变化对项目造成的影响进行评估，并与受影响的干系人协商，在取得一致意见后，方可进行修改。
没有控制的需求将导致产品计划推迟和较低的质量。在项目开发与运维过程中，持续的新需求与需求变更是不可避免的。如何管理和监控这些需求的变更过程，并相应调整开发计划和活动，保证这些需求能够被正确实现，是需求管理过程的重要内容。

3.2.1 需求收集

由申请人创建申请并提交；申请人需按照规定格式，将业务场景、需求内容等重要信息描述清楚。

3.2.1.1 工作内容

在此阶段，进行需求调研工作，通过开展需求调研、接受需求申请等主动或被动的方式，对系统的需求进行收集、提炼、归纳和汇总。

3.2.1.2 相关角色

产品经理，系统使用及相关人员

3.2.1.3 工作职责

产品经理是需求收集阶段的第一责任人，负责接收与系统相关的各个部门的需求申请，组织需求调研、分析、讨论和编写等工作。

3.2.1.4 需求类别

需求类别主要有以下几种：
   功能需求：包括界面、输入、输出、操作等
   性能需求：如容量、响应速度、吞吐能力等
  安全性需求：如加密、防攻击、防盗用等
  流程需求：如业务流程、业务场景等
  可维护性：包括日志、警告、跟踪等

3.2.1.5 需求表述

一个需求的表述，必须满足如下要素：
  清晰：需求的表述是从用户的角度来表达的，其必须清晰，不能模棱两可、含糊不清，不能有二义性。
  正确：需求必须真正代表了用户的需求，表述必须正确无误，引用数据和表述细节必须精确。
  可验证性：必须有明确的方法可以验证此需求是否被实现。
  全面：除了要表述正常过程下的需求，也要表述异常情况下的项目需求。

3.2.1.6 需求标识

每一个需求都必须被命名，并且用一个代码对其进行唯一标识。此代码用于需求管理的全过程。
命名规则为部门+需求名称的形式。例如销售部提出的需求，则命名为"销售-报价单新增单房差"。

3.2.1.7 需求测试验收

测试验收是用户确认系统是否满足了其需求的唯一依据。验收是按照需求逐项进行验收的。由于每一个需求都被标识，并且每一个需求都是可验证的，因此在需求阶段，验收测试表就必须提供，以明确项目系统的交付标准。

3.2.1.8 需求响应

接收用户需求后需要在一个工作日内响应。

3.2.2 需求初步审核

产品经理对申请内容进行初步审核，确认业务场景、需求内容等信息详实、准确、无二义性；如存在需要进一步核实的内容，由申请人确认并修改申请。

3.2.2.1 申请内容确认

产品经理在接到需求申请后，必须确认申请单以下内容填写完整，叙述准确、清晰且内容详实：需求来源、业务场景、需求描述、影响范围和价值。

3.2.2.2 申请内容修改

如果申请单内容存在需要进一步明确的地方，由产品经理提出修改意见，并由申请人修改后再次提交。

3.2.2.3 需求池管理表

通过初步审核的需求进入需求池管理表。

3.2.2.4 需求评审

产品经理进行进行原因分析、提出初步解决方案、确定重要程度。评审通过的需求进入禅道进行开发排期。

3.2.2.5 处理结果反馈

三个工作日内确认处理结果或计划并反馈给需求提出人。

3.2.3 需求设计

产品经理完成PRD文档及原型设计，协调UI设计师完成UI设计，并组织相关评审。

3.2.4 用户评审

产品经理基于原型，与需求提出者进行用户评审。通过用户评审后进入内部评审，不通过则回到需求分析阶段，重新进行原型设计、内部评审和用户评审。

3.2.4.1 内部评审

产品经理进行需求设计并制作需求原型，原型完成后组织内部评审。内部评审通过后进入研发阶段，不通过则修改原型后重新组织内部评审。开发人员基于原型及PRD文档，与项目经理、产品经理充分沟通后，评估开发工时。

3.2.5 需求解决

根据评审结果，配合研发制定研发计划，开展研发工作，并持续跟踪需求进度。

3.2.6 产品验收与发布

研发完成后产品经理完成内外部验收工作，UI设计师负责UI部分验收。并通知需求提出人及相关干系人。

3.3 需求持续跟踪与推广

需求研发完成发布后，产品经理负责向用户持续推广系统功能，方法包括但不限于邮件通知、系统操作手册、培训等，保证系统功能真正使用起来并达成需求目标。

第三章 研发管理制度

1 目的

为规范公司项目研发的执行过程，确保研发工作的高效安全可控，特制定该规范。

2 适用范围

公司自研项目，外采后进行二次开发的项目等涉及研发的项目均适用本制度。

3 研发活动的过程和职责

研发主要流程如下：

3.1 需求调研

产品经理对该阶段负责。产品经理负责与需求方和业务方沟通，深入了解客户需求，对需求进行收集\归类\整理，找出或引导客户找到真正需求点。如果客户有对标产品，产品经理需要进行竞品分析和比较，该阶段产出需求分析报告。

3.2 可行性分析

产品经理与相关研发同事，可以与研发经理、架构师和高级工程师就产品中的一些核心技术确定技术可行性。确定技术初步方案。

3.3 产品需求

产品经理根据用户故事进行需求设计。产出产品需求文档(PRD)，必要时还需要产需求原型和交互设计模型。产品需求文档需要包含需求的业务逻辑，产品的全部验收点。

3.4 技术调研

在进行一些较为复杂或超前的项目时，研发需要对相关技术难点进行调研，必要时需要编写核心代码或者DEMO来验证技术的可行性，以及方案的相关技术指标。该过程由负责调研的人员或者研发产出技术调研报告。必要时进行DEMO演示或执行MVP项目开发。

3.5 界面设计

根据产品需求进行UI设计，产出UI设计文档和UI资源，对资源进行标注。项目研发时交付给相关研发人员

3.6 需求评审

产品经理召集研发对已经确认的需求进行技术评审。参与人员包含 后端研发，前端研发，QA。研发需要对产品PRD和原型提出疑问。产品经理对疑问点进行解释或者补充。确保整个功能的相关人员理解一致。

3.7 技术设计评审

该阶段根据根据产品的复杂度进行调整。如果业务逻辑较为复杂技术需要出技术方案。技术方案根据需要包含 ，业务流程图，数据库关系图，时序图。类图。技术设计完成后由相关研发和QA进行技术评审。通过评审后，技术开发要严格按照设计进行开发。由技术负责人或者技术委员会进行验收。

3.8 用例评审

需求确定后，QA 相关同事需要产出测试用例。根据story情况可以优先产出冒烟测试用例。理论上要在story开始的第一天或者第二天给出当前story的冒烟测试。用例设计完成后由QA组织评审会议，邀请产品和相关研发参与。

3.9 技术研发阶段职责

研发过程各级职能的任务如下

3.9.1 架构师

架构师应在研发前完成技术架构规划和研发框架搭建，全过程提供技术支持。

3.9.2 产品

负责解答研发过程中的疑问。
负责测试完成后功能验收。
负责发布清单的制作以及发版后系统配置、用户通知工作。

3.9.3 后端研发与前端研发交互

根据Wiki《前后端交互接口规范》约定，前后端研发同时启动研发。

3.9.4 后端研发

根据PRD文档输出接口文档，完成编码和单元测试。
发版准备工作及配合版本发布，发版过程问题处理。

3.9.5 前端研发

根据PRD文档实现业务逻辑，根据UI图实现界面设计，并按照后端规定进行异常处理。
发版准备工作及配合版本发布，发版过程问题处理。

3.9.6 测试

进行接口测试，功能测试，跟踪story进度，发布每日的记录跟踪报告，发布测试报告，确保研发的产品符合PRD要求。

3.9.7 UI设计师

根据产品经理设计输出UI设计，进行UI验收，确保用户界面和交互流程符合设计师的预期设计。

3.9.8 产品验收

QA对story测试完成后，使项目达到可交付状态，负责该story的QA在项目管理工具上将story提交给产品进行产品验收。根据story的复杂度产品需要在指定时间完成产品验收。

3.9.9 发布评审和产品上线

根据项目的规模和受影响的情况来决定是否需要进行发布评审，发布评审由QA发起，邀请相关研发，运维参与。产品上线由QA发起，提供发布列表和发布检查项列表，测试报告，发布列表包含QA与研发确认需要发布的项目列表和相关配置以及数据升级内容。QA的发布申请邮件需要发送给项目干系人和研发leader。 发布列表: 发布列表包含发布的项目(Jenkins job)和相关联的项目
发布检查项列表：checklist根据实际情况提供，包含发布需要修改的配置，发布的前置和后置操作，比如 SQL语句，配置项目等等。
测试报告：包含项目的质量报告，能否发布的结论，以及项目中存在的风险点，以及异常处理方案等

3.9.10 预发布验收和生产发布

发布预发布环境后，QA进行冒烟测试以及主流程测试。完成后通知产品进行预发布验收。产品验收完成后由运维发布生产环境，发布后产品发送邮件告知业务方。产品邮件需要包含，新功能说明，功能限制和风险说明，必要时也可以将功能的未来规划告知业务方。

3.9.11 培训和答疑

根据实际需要，产品负责编写产品使用说明书，对业务方进行培训和答疑，以帮助业务方按照产品的规划的方式来使用相应的功能。

4 源代码管理

4.1 分支的使用

master分支：用于线上发布，每个sprint从master拉出一个分支。命名为sprint的名称，例如: sprint20190320，该分支对应到生产站

sprint分支：sprint分支主要用于发布和QA测试。该分支对应到QA站和预发布站。Sprint分支是迭代的主分支每个sprint分支按预计发布日期进行命名。比如: 2021年7月20日发布的sprint则命名为 sprint-20240720

feature分支：用于进行新功能开发，研发人员从当前sprint分支拉出feature分支进行新功能的开发。feature分支命名为feature-[日期yyyyMMdd(和sprint日期一致)]-[开发人英文]，例如: feature-20240720-zouyu。该分支对应本地或DEV环境。

Bug分支：

1.分支用于进行紧急线上问题修复。命名为 bug-[发布日期]，例如 bug-20240720

2.如果多人修复预计发布日期一致，需在bug-[发布日期]分出个人分支修改，再合并到bug-[发布日期]， 例如 bug-20240720-zouyu

4.2 代码合并流程

代码合并原则为确保代码的单向流动，代码从Master分支往sprint ， feature 分支流动。BUG修复后代码合并到master之后再由master流向sprint 等分支。 代码合并流程图如下:

4.3 代码审查

提交到主分支(包含master，sprint等分支)的代码必须经过代码审查。通过使用gitlab的merge-request 功能进行代码审查。未经审查的代码无法合并到主分支。提交merger-request请求时需指定有代码审查权限的人员进行代码审核。审核通过的代码会被自动合并到主分支。

4.4 代码安全

公司研发项目相关的源代码访问权限由运维统一管理，研发人员代码访问权限需要执行最小权限原则，禁止相互拷贝代码。

第四章 测试管理制度

1 目的

在软件开发的过程中，测试的主要目标是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷保障软件质量，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误；采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量。

2 规范及流程

2.1 测试计划

测试在确认需求描述已经明确后，基于需求紧急程度与研发预估的开发计划，进行测试任务拆分与任务工时预估，进而确定各需求的测试计划，形成迭代或项目的测试整体计划。
测试计划确定后，由项目经理结合迭代或项目整体计划进行确认，最终形成确定的测试计划。

2.2 测试用例

在完成需求评审后，测试开始编写测试用例。测试用例内容包括：用例ID/功能点/用例说明/前置条件/输入/预期输出/测试结果等。
项目经理基于用例完成进度，组织测试用例评审，评审人包括：产品经理，研发，测试。测试人员对测试用例进行说明，产品经理确认测试用例是否贴合需求设计，研发人员根据测试用例辅助开发工作。
用例评审由测试评估是否需要，若需要由测试发起，产品、研发需要参与。

2.3 测试执行

2.3.1 功能测试

在研发完成联调及自测后，提交测试。测试基于测试用例进行测试，确保正确性并符合功能设计。

2.3.2 集成测试

在完成所有需求与功能的测试后，针对需求涉及的所有功能模块进行集成测试。确认修改的需求不影响相关功能的正常使用。

2.3.3 回归测试

在版本发布前1周，针对系统全体功能模块进行回归测试。
回归测试开始前，项目经理确认是否还有未结束开发的功能或错误。如有，则需制作未完成功能列表，并判定其影响范围。
测试人员对全模块重复以前的测试。确认核心测试模块，对核心模块进行重点测试。并确认没有损害原有的正常功能。

2.3.4 用户测试

预发布环境版本发布后，由项目经理组织用户对功能进行验收活动，并由产品经理记录用户反馈，确定是否要在后续迭代中进行调整。

第五章 运维管理制度

1 目的

为保障公司信息系统软硬件设备的良好运行，使信息部员工的运维工作制度化、流程化、规范化，故对运维管理做出相关规定。

2 名称解释

无

3. 规范及流程

运维管理制度的适用范围为信息部运维人员。运维服务管理体系规定了运维活动涉及的各类实体，以及这些实体间的相互关系。相关的实体在运维服务管理体系中进行有机组织，并协调工作，按照服务协议要求提供不同级别的IT运维服务。主要流程如下：

3.1 运维服务对象

包括基础设施、应用系统、客户、供应商、用户和IT人员，具体内容如下：

• 基础设施包括服务器、网络、操作系统、存储/备份系统、终端系统、安全系统、以及机房等。
• 应用系统包括内部办公系统、门户网站，面向客户、供应商或公众的应用系统等。
• 用户包括使用如上应用系统的用户。
• 供应商包括基础设施和应用系统的供应商以及IT运维服务的供应商。
• IT人员包括内部参与运维活动的部门内部人员。

3.2 运维服务内容

运维提供的服务包括：信息系统相关的主机设备、操作系统、数据库和存储设备的运行维护服务，保证用户现有的信息系统的正常运行，降低整体管理成本，提高网络信息系统的整体服务水平。同时根据日常维护的数据和记录，提供用户信息系统的整体建设规划和建议，更好的为用户的信息化发展提供有力的保障。
用户信息系统的组成主要可分为两类：硬件设备和软件系统。硬件设备包括网络设备、安全设备、主机设备、存储设备等；软件设备可分为操作系统软件、典型应用软件（如：数据库软件、中间件软件等）、业务应用软件等。
服务项目范围覆盖的信息系统资源以下方面的关键状态及参数指标：

• 运行状态、故障情况
• 配置信息
• 可用性情况及健康状况性能指标

3.3 网络、安全系统运维服务

从网络的连通性、网络的性能、网络的监控管理三个方面实现对网络系统的运维管理。包括以下内容：

• 设备基础性能检测：cpu、内存使用情况监测；
• 设备日志查看；
• 设备snmp状态；
• 测试Ping，tracert等工具的连通性；
• 网络安全策略应用是否正常；
• Internet带宽流量的实时监测；
• 网络拓扑链路状态监测；
• 异常网络数据包流量；
• Dos、ddos等网络攻击情况监测；
• Internet线路的误码率、丢包率监测；在系统设计阶段中，用户应充分参与，确保系统设计能满足系统需求。

3.4 主机、存储系统运维服务

提供的主机、存储系统的运维服务包括：主机、存储设备的日常监控，设备的运行状态监控，故障处理，操作系统维护，补丁升级等内容。进行监控管理的内容包括：

• CPU 性能管理；
• 内存使用情况管理；
• 硬盘利用情况管理；
• 系统进程管理；
• 主机性能管理；
• 实时监控主机电源、风扇的使用情况及主机机箱内部温度；
• 监控主机硬盘运行状态；
• 监控主机网卡、阵列卡等硬件状态；
• 主机系统文件系统管理；
• 监控备份服务进程、备份情况（起止时间、是否成功、出错告警）；
• 对存储的性能（如高速缓存、高速网络通道等）进行监控。

3.5 数据库系统运维服务

提供的数据库运行维护服务是包括主动数据库性能管理，数据库的主动性能管理对系统运维非常重要。通过主动式性能管理可了解数据库的日常运行状态，识别数据库的性能问题发生在什么地方，有针对性地进行性能优化。同时，密切注意数据库系统的变化，主动地预防可能发生的问题。
进行监控管理的内容包括：

• 数据库基本信息：文件系统、碎片、死锁、CPU占用率较大或时间较长的SQL语句。
• 表空间使用信息监测；
• 数据库文件I/0读写情况；
• Session连接数量监控；
• 数据库监听运行状态监测；
• 查看每日数据备份、数据同步是否正常；
• 报警日志监测；
• 对表和索引进行Analyze，检查表空间碎片；
• 检测数据库后台进程；
• 数据库对象的空间扩展情况监测；
• 数据备份恢复演练。

3.6 中间件及应用程序运维服务

中间件管理是指对Tomcat、MQ等中间件的日常维护管理和监控工作，提高对中间件平台事件的分析解决能力，确保中间件平台持续稳定运行。中间件监控指标包括配置信息管理、故障监控、性能监控。应用程序包括自研或采购的应用软件的维护和管理。

• 执行线程：监控中间件配置执行线程的空闲数量。
• JVM内存：JVM内存曲线正常，能够及时的进行内存空间回收。
• JDBC连接池：连接池的初始容量和最大容量应该设置为相等，并且至少等于执行线程的数量，以避免在运行过程中创建数据库连接所带来的性能消耗。
• 检查中间件日志文件是否有异常报错。
• K8s等容器编排工具和容器部署的管理。
• 应用软件部署及日常监控。

3.7 数据迁移

提供数据迁移技术服务，负责迁移方案、计划、实施、验证等工作，确保数据迁移工作正确执行。

• 负责制定数据迁移计划，与交付过程中的周边团队和人员配合。
• 调研制定迁移方案（包括回退方案），组织干系人对输出文档的评审。
• 负责各个局点的割接设计和割接需求的分析澄清工作，输出割接策略文档和设计规格（映射文档）。
• 负责跟踪问题列表，并能识别项目风险，及时预警和推动。
• 组织干系人对迁移结果进行验证。

3.8 故障分级及响应措施

3.8.1  服务时间
3.8.1.1 在5*8 小时工作时间内设置由专人职守的热线电话，接听内部的服务请求，并记录服务台事件处理结果。
3.8.1.2 在非工作时间设置有专人7*24 小时接听的移动电话热线，用于解决内部的技术问题以及接听7*24 小时机房监控人员的机房突发情况汇报。
3.8.1.3 故障响应时间：

3.9 其他

其他与运维组相关流程请参见附件1

第六章 项目管理制度

1 目的

软件项目管理过程中，不仅要实现项目的范围、时间、成本和质量等目标，还必须要协调整个项目的推进，以满足项目干系人及其他利益相关者的需要和期望。
严谨的项目过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差、识别项目的风险，还可以将人才流动所带来的不利影响减少到最小。

2 规范及流程

主要流程如下：

要进行全面的、有效的项目管理，必须明确项目管理的流程。总体来讲，项目可以分为启动、计划、执行、控制和收尾五个阶段。

2.1 项目启动

启动阶段是一个新项目的开始。启动软件开发等信息技术项目，必须了解企业在目前和未来的主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境。启动信息技术项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。
项目启动必须包含两个方面的重要内容，一是项目章程的制定，二是干系人识别。

2.1.1 项目章程

制定项目章程，包含如下重要步骤：
 制定项目章程前，任命项目经理。
 制定项目章程的输入应包括：项目工作说明书和商业论证。
 项目章程主要内容应包括：项目背景；项目目标和成功标准；概括性描述与边界定义；干系人的基本信息与职权等。
 项目章程主要作用包括：批准项目；任命项目经理；授权使用资源。
 项目章程仅能由项目以外的人员（如发起人）批准。
由申请人创建申请并提交；申请人需按照规定格式，将业务场景、需求内容等重要信息描述清楚。

2.1.2 干系人识别

对于干系人识别，存在以下注意事项：
 项目立项时，就要识别干系人，并制作干系人登记册。
 随着项目的推进，干系人识别应持续进行，并定期更新干系人登记册。
 干系人登记册应包括以下内容：
（1） 基本信息：姓名，职位，联系方式等。
（2） 评估信息：主要需求及期望，对项目的潜在影响。
（3） 干系人分类：内部/外部，支持者/中立者/反对者。

2.2 项目计划

项目计划涉及范围、进度、成本、风险等多个项目管理知识领域。计划制定后，项目的实施阶段将严格按照计划进行控制。今后的所有变更都将是因与计划不同而产生的。
项目计划阶段，必须针对以下各方面制定相应的管理计划。

2.2.1 范围管理计划

合同项目应以合同和招投标文件为依据，非合同项目应以可行性研究报告或项目前期调研成果为依据，明确项目范围。制定范围管理计划的主要过程应包括：

2.2.1.1 规划范围管理

描述如何管理范围，降低范围蔓延风险。

2.2.1.2 收集需求

定义并记录需求，为定义和管理范围奠定基础。

2.2.1.3 定义范围

制定项目和产品详细描述，生成范围说明书。

2.2.1.4 创建WBS

以可交付物为导向进行分解，生成范围基准。
这里的项目的应交付成果不仅是指项目的最终产品，也包括项目的中间产品。例如通常情况下软件开发项目的项目产品可以是：需求规格说明书、概要设计说明书、详细设计说明书、测试计划、测试报告、程序代码与程序文件、程序安装文件、用户手册、验收报告、项目总结报告等。

2.2.2 进度管理计划

制定进度管理计划的主要过程应包括：

2.2.2.1 规划进度管理

为如何在整个项目过程中管理项目进度提供指南和方向。

2.2.2.2 定义活动

从项目目标开始，从上到下，层层分解，确定实现项目目标必须要做的各项工作，并画出完整的工作分解结构图。软件开发项目刚开始可能只能从阶段的角度划分，如需求分析工作、架构设计工作、编码工作、测试工作等。

2.2.2.3 任务排序

在资源独立的假设前提下确定各个任务之间的相互依赖关系，以确定各个任务开始和结束时间的先后顺序。

2.2.2.4 确定每个任务所需的时间

根据经验或应用相关方法确定任务需要耗费的时间，以及确定每个任务所需的人力资源要求。

2.2.2.5 制定进度计划

根据以上结果编制项目总体进度计划，总体进度计划应当体现任务名称、责任人、开始时间、结束时间、应提交的可检查的工作成果。

2.2.3 成本管理计划

制定成本管理计划的主要过程应包括：

2.2.3.1 规划成本管理

规定如何管理成本。确定计量单位，精准度，临界值等基本规则。

2.2.3.2 估算成本

对活动所需的资金进行近似估算。可使用类比估算、参数估算、三点估算、自下而上估算等方法。

2.2.3.3 制定预算

生成成本基准，用来控制项目绩效。预算应该经过批准且按时间段分配资金。

2.2.4 风险管理计划

制定风险管理计划的主要过程应包括：

2.2.4.1 规划风险管理

规划如何实施风险管理，确保风险管理的程度与项目的重要性相匹配。主要包括风险概率和影响定义，干系人承受力等。

2.2.4.2 识别风险

对风险文档化，为预测未来事件积累经验。

2.2.4.3 风险定性分析

评估概率和影响，风险排序，分清轻重缓急，关注高优先级风险。

2.2.4.4 风险定量分析

对定性分析中识别出的重要风险，进行量化分析。可使用敏感性分析、预期货币价值分析等技术。

2.2.4.5 规划风险应对

制定积极风险/消极风险的应对方法，一般包括规避、转移、减轻、接受等。

2.2.5 人力资源管理计划

2.2.5.1 确定项目团队的组织结构

包括管理、开发、测试、QA、评审、验收等。

2.2.5.2 确定项目团队人员及分工

确定项目团队人员构成。如内部不能满足人员需求，则提出人员支援申请。

2.2.6 沟通管理计划

2.2.6.1 明确与用户的沟通方法

明确最终用户、直接用户及其所在企业／部门名称和联系电话。用户更多的参与是项目成功的重要推动力量，加强在开发过程中与用户方配合人员的主动沟通。

2.2.6.2 汇报方法

采用周报或月报的方式通告项目的进展情况和下一阶段计划。必要时，采用日报的方式沟通项目最新进展。

2.3 项目执行与控制

2.3.1 项目执行阶段

项目执行阶段必须按照计划阶段制定的计划采取必要的活动，来完成计划阶段制定的任务。在执行阶段中，应将项目按技术或功能类别分成不同的任务，由项目团队中的不同的成员来完成各个任务的工作。

2.3.2 项目控制阶段

项目控制阶段主要是在项目进行的过程中对项目进行监督和控制。主要包括：
  控制执行进度，进行合理调整。
  控制项目的实际投入，保证投入的合理性，保证后续阶段的可持续性。
  控制监督项目的实际结果，保证阶段结果与阶段进程计划相同或相符。
  控制项目实施中的困难和阻力，提出建议性措施和解决方法，避免项目的重大停顿或中止。

2.3.3 变更控制

当项目的某些基准发生变化时，项目的进度、质量和成本等从而发生变化，为了达到项目的目标，就必须对项目发生的各种变化采取必要的应变措施，这种行为称为项目变更。
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

2.3.3.1 引起变更的因素

来自外部的变更要求，如用户要求修改工作范围和需求等。
开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。

2.3.3.2 应对变更的原则

为了对项目的变更进行有效地控制，成功地完成项目的目标，项目变更应遵循以下原则：
  选择影响最小的方案。
  所有的变更在准备变更申请和评估之前，必须与项目经理进行商讨。
  及时发布项目的变更信息。

2.3.3.3 关于变更控制程序的规定

变更程序应严格按照以下步骤执行：
  接受变更，明确变更内容。
  书面记录并提交申请。
  评价变更对项目所有因素造成的影响。
  设计策略与应对方案。
  向变更控制委员会提交变更请求。
  变更控制委员会批准或拒绝变更请求。记录变更日志，更新项目计划或标准，通知受影响的干系人。
  确保变更合理实施。

2.4 质量管理与控制

2.4.1 质量保证

质量保证应对质量要求及质量控制测试结果进行审计，包括测试用例设置是否全面，测试流程是否合理，测试报告中测试指标是否合适等。
在质量保证推进过程中，应不断发现问题并对过程进行改善。

2.4.2 质量控制

质量控制要求必须对可交付成果在质量上进行确认，确认方法包括因果图，控制图等。

2.5 项目收尾

项目收尾是软件项目生命周期的最后阶段，收尾程序必须包括以下步骤：
  确定具体收尾程序
  移交项目成果。这是收尾成功的一个基本的前提。
  经验教训总结。这是项目可持续发展的必要，也是对项目和项目组成员的尊重。
  文件审核/归档。不仅要对项目的程序代码存储，所有相关文档资料（包括合同、开发文档、总结文档等）也要归档。
  资源遣散

第七章 加班管理制度

1 目的

为规范部门加班管理，保障员工身心健康，充分利用正常工作时间，提高工作效率，特制定本制度。

2 加班认定标准

在规定的工作时间外，因工作需要，需要在工作日、周末、法定节假日延长工作时间的，通过人事系统（eHR）申请，经部门负责人审批通过后，视为加班。

3 申请与审批

3.1计划内加班，加班结束当日内，需通过人事系统（eHR）提交加班申请，注明加班事由、工作产出。

3.2计划外加班，包括但不限于系统重大升级、紧急故障处理等需临时中断日常工作的任务或经部门负责人预先授权的突发性项目支持等，需注明故障编号/影响范围/支持项目，并在加班结束1天内，完成人事系统（eHR）补流程申请。

4 调休原则

公司优先安排员工调休

4.1 调休优先：加班时间与调休时间原则上按照 1:1 的比例进行兑换，如有特殊原因，需与人事行政部商定后执行。

4.2 ​有效期：调休有效期至次年第一季度结束，如若特殊情况，需与人事行政部沟通后执行。

5 健康保障

5.1 连续加班超过3天或单日超过22:00，可申请次日调休半天。

5.2 加班超过22:00，公司提供打车费报销，报销时参照公司费用标准执行。

6 其他

6.1 加班管理制度与人事行政部制度冲突时，以人事行政部制度为准。

6.2 加班管理制度解释权归信息技术部及人事行政部所有。