...
Table of Contents absoluteUrl true
第一章 总则
1 目的
为了保护公司计算机信息系统安全,推进公司数字化转型建设,保证公司信息系统正常运行,加强产品、研发、测试、运维、项目管理等管理工作,提升工作效率以及各工作环节协同配合度,特制定本制度。
2 适用范围
本公司服务器、网络等基础设施,自研项目、实施项目等管理事宜均适用本制度。
第二章 业务需求管理制度
1 目的
为了规范需求管理的过程和活动、更加有效地利用信息技术部的技术资源,故对业务需求管理做出相关规定。
2 名词解释
业务需求:指业务部门或外部用户对现有正常使用的系统提出新的功能、报表要求;或者业务部门针对某项业务提出的新建系统需求。
3 规范及流程
在建项目实施过程中的业务需求由产品经理负责,项目经理协助;日常工作中出现的业务需求由申请人在钉钉上填写《信息化需求申请》,由产品经理负责追踪反馈。
自研与外采系统需求管理流程如下:
...
需求研发完成发布后,产品经理负责向用户持续推广系统功能,方法包括但不限于邮件通知、系统操作手册、培训等,保证系统功能真正使用起来并达成需求目标。
第三章 研发管理制度
1 目的
为规范公司项目研发的执行过程,确保研发工作的高效安全可控,特制定该规范。
2 适用范围
公司自研项目,外采后进行二次开发的项目等涉及研发的项目均适用本制度。
3 研发活动的过程和职责
研发主要流程如下:
3.1 需求调研
产品经理对该阶段负责。产品经理负责与需求方和业务方沟通,深入了解客户需求,对需求进行收集\归类\整理,找出或引导客户找到真正需求点。如果客户有对标产品,产品经理需要进行竞品分析和比较,该阶段产出需求分析报告。
...
根据实际需要,产品负责编写产品使用说明书,对业务方进行培训和答疑,以帮助业务方按照产品的规划的方式来使用相应的功能。
4 源代码管理
4.1 分支的使用
master分支:用于线上发布,每个sprint从master拉出一个分支。命名为sprint的名称,例如: sprint20190320,该分支对应到生产站
...
公司研发项目相关的源代码访问权限由运维统一管理,研发人员代码访问权限需要执行最小权限原则,禁止相互拷贝代码。
第四章 测试管理制度
1 目的
在软件开发的过程中,测试的主要目标是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷保障软件质量,避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。同时利用测试过程中得到的测试结果和测试信息,作为后续项目开发和测试过程改进的重要输入,避免在将来的项目开发和测试中重复同样的错误;采用更加高效的测试管理手段,提高软件测试的效率和软件产品的质量。
2 规范及流程
2.1 测试计划
测试在确认需求描述已经明确后,基于需求紧急程度与研发预估的开发计划,进行测试任务拆分与任务工时预估,进而确定各需求的测试计划,形成迭代或项目的测试整体计划。
测试计划确定后,由项目经理结合迭代或项目整体计划进行确认,最终形成确定的测试计划。
...
预发布环境版本发布后,由项目经理组织用户对功能进行验收活动,并由产品经理记录用户反馈,确定是否要在后续迭代中进行调整。
第五章 运维管理制度
1 目的
为保障公司信息系统软硬件设备的良好运行,使信息部员工的运维工作制度化、流程化、规范化,故对运维管理做出相关规定。
2 名称解释
无
3. 规范及流程
运维管理制度的适用范围为信息部运维人员。运维服务管理体系规定了运维活动涉及的各类实体,以及这些实体间的相互关系。相关的实体在运维服务管理体系中进行有机组织,并协调工作,按照服务协议要求提供不同级别的IT运维服务。主要流程如下:
...
故障级别 | 响应时间 | 故障解决时间 |
P0级:属于致命问题;其具体现象为:系统崩溃导致业务停止、数据丢失。 | 10分钟,30分钟内提交故障处理方案 | 3小时以内 |
P1级:属于严重问题;其具体现象为:出现部分部件失效、系统性能下降但能正常运行,不影响正常业务运作。 | 10分钟,30分钟内提交故障处理方案 | 6小时以内 |
P2级:属于一般问题;其具体现象为:出现系统报错或警告,但业务系统能继续运行且性能不受影响。 | 10分钟,30分钟内提交故障处理方案 | 12小时以内 |
P3级:属于轻微问题;其具体现象为:系统技术功能、安装或配置咨询,或其他显然不影响业务的预约服务。 | 10分钟,2小时内提交故障处理方案 | 24小时以内 |
3.9 其他
其他与运维组相关流程请参见附件1
第六章 项目管理制度
1 目的
软件项目管理过程中,不仅要实现项目的范围、时间、成本和质量等目标,还必须要协调整个项目的推进,以满足项目干系人及其他利益相关者的需要和期望。
严谨的项目过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差、识别项目的风险,还可以将人才流动所带来的不利影响减少到最小。
2 规范及流程
主要流程如下:
要进行全面的、有效的项目管理,必须明确项目管理的流程。总体来讲,项目可以分为启动、计划、执行、控制和收尾五个阶段。
...
项目收尾是软件项目生命周期的最后阶段,收尾程序必须包括以下步骤:
确定具体收尾程序
移交项目成果。这是收尾成功的一个基本的前提。
经验教训总结。这是项目可持续发展的必要,也是对项目和项目组成员的尊重。
文件审核/归档。不仅要对项目的程序代码存储,所有相关文档资料(包括合同、开发文档、总结文档等)也要归档。
资源遣散
第七章 加班管理制度
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 加班管理制度与人事行政部制度冲突时,以人事行政部制度为准。
...