开发部工作制度V10.docx
- 文档编号:8515180
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:9
- 大小:67.50KB
开发部工作制度V10.docx
《开发部工作制度V10.docx》由会员分享,可在线阅读,更多相关《开发部工作制度V10.docx(9页珍藏版)》请在冰豆网上搜索。
开发部工作制度V10
开发部工作制度()
2018-3-14
1.日常
1.1.遵守公司各项规章制度。
1.2.工作时间(包括加班)严禁玩游戏,严禁浏览与工作无关的网站,否则当日考核不合格。
1.3.工作时间离开岗位(或者请假)应向其他同事交待,外出应向部门经理或项目负责人和相关同事进行说明,不能耽误项目组的工作。
1.4.每一个岗位(除见习岗位)的人员离职前都必须培养出能接替自己工作的人员,离职人员,必须提前一个月通知部门经理,有一个月的交接时间,交接完毕方可离职。
1.5.开发部人员的日常工作安排由部门内部决定,和其他部门的接口必须通过部门经理、项目负责人协调,以减少开发人员不必要的时间支出,提高开发效率。
如果由此导致的不能正常完成工作计划,责任自负,本周工作考核为不合格。
1.6.严禁代替其他同事打卡。
1.7.严禁不经部门负责人同意,擅离岗位,否则按照旷工处理。
1.8每个人的工作日志必须每天一交,每个人的工作日志,每天发到部门经理和相应的项目经理处,不能完成的需要当面说明。
2.职务划分
2.1.部门经理
负责本部门的总体管理工作,包括:
人员分配与管理,人员招聘,制定部门工作计划,进行工作考评,文档管理和质量管理,协调与其他部门的关系,向公司主管领导提出产品开发建议。
2.2.项目经理
协助部门经理做好本项目组的开发、管理和考核工作,安排项目现场问题处理人员;分管应用开发、硬件开发工作,有问题及时汇报。
3.岗位划分
3.1.系统工程师
负责需求评审,系统开发的解决方案,确认和解决技术难题,设计评审,监督开发文档质量,整理现有系统版本,帮助见习工程师尽快进入工作状态,协助工程人员处理工程现场问题,审核测试计划、测试大纲、测试报告,并根据测试报告提出下一步的开发计划。
担任大型项目的负责人。
3.2.高级开发工程师
分析、设计和实现系统开发和应用开发需求中提出的功能特性,完成代码测试,并协助测试工程师进行模块测试和系统测试,进行系统维护,协助工程人员处理工程现场问题。
帮助见习工程师尽快进入工作状态。
担任中型项目的负责人。
3.3.测试工程师
负责本部门开发测试环境的搭建,编写开发项目的测试计划、测试大纲,完成软件产品的模块测试和系统测试,编写测试报告,完成配置管理和质量管理。
3.4.开发工程师
分析、设计和实现应用开发需求中提出的功能特性,完成代码测试,并协助测试工程师进行模块测试和系统测试。
系统维护,协助工程人员处理现场问题。
帮助见习工程师尽快进入工作状态。
担任小型开发项目的负责人。
3.5.见习工程师
所有刚进入开发部工作的人员都有三个月的见习期,这段时间主要工作是接受简单的工作培训(从设备接入程序编写开始),然后进入系统维护工作。
见习期满后,若通过考核,则转入开发或测试工程师的岗位。
否则根据情况延长见习期或交给公司人力资源部门。
4.组织架构
4.1.组织架构安排原则
开发部内部组织架构原则采用项目组的形式运行,每个项目组由项目经理负责,每个项目组根据实际情况配置多名项目组成员,项目组成员由不同级别的工程师组成,尽量保证每个项目组的开发力量均衡,达到每个项目组能够充分发挥“传帮带”的作用。
尽可能发挥每个人的专业特点性,提高了整个项目组的工作效率,提高整个开发部门的管理水平。
4.2.团队合作
每个项目的成功实施都是由项目组的各位成员积极努力配合的结果,离不开团队的每个成员的工作和支持,希望大家团结互助,互敬互爱。
4.3.组织架构图
5.流程
5.1.开发部的工作类别
1)系统开发:
主要指新系统开发;现有系统功能规模较大的升级;基本共享库或工具开发。
新系统的开发由公司统一决策立项;系统功能升级由用户或市场部门提出,经公司主管领导和技术部门讨论立项;基本工具或共享库的立项由本部门提出。
2)应用开发:
主要内容为各种应用模块的开发或改写,实验室仿真测试,现场测试。
根据市场部门所签订项目合同中技术协议部分的要求立项,
3)系统维护:
包括根据用户反馈修正运行系统中出现的缺陷,对系统开发和应用开发过程中形成的程序进行代码重构和优化,版本整合和归档,现场技术支持等所有未包括在系统开发和应用开发中的内容。
5.2.工作流程
5.2.1.原则
1)所有任务都由统一接口提交给开发部;
2)每一项任务都看成一个项目;
3)每一项目都有一个责任人;
4)人员可以并行参加几个项目;
未涉及到的环节参考公司现有的质量文件中关于“开发项目管理控制程序”文件中相关部分。
开发项目提交到开发部后,由开发部经理指定项目负责人,并和项目负责人共同组织项目组成员。
项目负责人负责项目的组织工作,并协调与其他项目之间的关系,协调不成功的由部门经理或者公司主管领导负责协调,尽量保证工作能够正常顺利进行。
系统开发项目流程见《基础产品开发流程》;
应用开发项目或突发的系统维护工作流程见《应用开发流程》;
6.文档
以下各项工作文档是开发部工作过程中产生的,分为“必需”和“试行”两类。
“必需”文档作为工作评价的主要依据,是强制执行的;“试行”文档是根据目前情况未强制执行,但在今后要逐步推行的。
其他一些未列出的文档见质量部的相关规定。
6.1.工作日志(必需)
6.1.1.内容
1)今日工作:
是每日的工作汇报。
主要填写本工作日内的内容。
以及需要交流的信息等。
2)明日计划:
明日的工作安排。
加班报告:
如在工作日内超额时间工作,可填在此处。
并注明:
《超额时间》:
精度为一个小时。
《加班内容》:
加班的工作内容。
注:
如在周六,日进行加班工作,则报告可以填写在下周一的工作日志中。
6.1.2.时间
每个工作日。
在现场出差期间,用出差报告代替。
6.1.3.格式
【
今日工作:
(分别列出各项工作并注明花费时间)
工作进度:
遇到问题:
解决方案:
处理结果:
明日计划:
加班报告:
附件:
需要提交的附加文件
】
6.2.项目日志(必须)
每个项目都维护一个开发项目日志,用来记录原始材料,包括初步的需求,设计草案,项目变更,项目会议纪要等内容。
由项目负责人保管,记录者可以是参加项目的任何成员。
时间和格式自定。
6.3.出差计划及报告(必需)
出差期间代替工作日志。
6.4.故障处理报告(试行):
参见原《故障处理报告》。
6.5.进度报告(必需)
内容:
接手的各项工作的进展情况,包括已经完成的;未完成的;和计划的一致程度;落后或超前原因
时间:
每月月末
格式:
自定
6.6.需求评审记录(必需)
内容:
项目名称;合同签订时间;参加人员;需求简要列表;对每一条需求的评审意见
时间:
接到开发需求通知后一天之内
格式:
见质量文档
6.7.需求说明书(必需)
参开发部《需求规格说明书与技术分析报告》
6.8.任务计划书(必须)
参见原《项目开发计划》
6.9.变更记录(必需)
参见原《需求计划变更表》
6.10.设计说明书(必需)
参见原《设计说明书》,但要包含流程图(面向过程)或类图(面向对象)
6.11.设计评审记录(必须)
参见原《设计评审记录表》
6.12.源程序(必需)
参见《SCBJ/HR编程风格》
6.13.测试计划及报告(必须)
参见《软件产品测试大纲编写规范》
6.14.使用说明书(用户手册)(必需)
内容:
阅读对象;操作步骤;注意事项
时间:
任何有外部用户(包括最终用户,工程人员,或其他开发人员)的软件程序或硬件模块在开发完成并测试通过后,交付之前。
格式:
自定
6.15.使用说明书验收报告
每个产品,项目出场之前,必须要有使用说明书,使用说明书必须经过评审签字。
6.16.阶段工作总结报告(必需)
内容:
承担的任务描述;完成情况;问题所在;经验总结;对部门的意见或建议
时间:
月考评前和年考评前
格式:
自定
6.17.项目总结报告(必需)
参见原《项目总结报告规范》
6.18.会议纪要(必须)
内容:
议题;参加人员名单;会议时间;会议主要发言内容;决议
时间:
会议召开后一天内
格式:
自定
7.配置
7.1.在部门中设置配置管理员,负责部门中测试系统的正常运行和开发产品的版本管理和归档工作。
7.2.在开发部建立“版本管理系统”,“BUG管理系统”,“开发部测试系统”,“产品发布环境”。
7.3.未在版本管理系统上工作的开发人员,要保持版本跟踪的手工记录,因为没有版本跟踪记录而造成混乱或项目现场故障的要追究当事人的责任。
8.会议
8.1.部门或项目组根据需要确定相应的会议;会议分为定期会议和临时召集会议。
8.2.定期会议包括每周一上午或者下午召开的周工作例会,每月底召开的月工作进度会议。
周工作例会由部门经理主持,主要内容是讨论上周工作进度和存在的问题,并汇报下周工作安排。
每月底的月工作进度会议检查本部门的本月的实际工作进度和计划进度的一致性,并讨论改进意见。
8.3.临时召集会议包括除了以上两个例会以外任何部门范围内的会议,会前由会议发起者通知相关与会人员,根据需要与会人员准备与此次议题相关的材料,会议发起者制定会议议程,并主持会议。
8.4.每次会议必须要有纪要,重要会议必须由部门会签确认。
会议纪要在会后应分发给与会人员,并在部门内存档。
8.5.每次会议形成的决议必需得到落实,要在下次会议前检查上次会议决议的执行情况。
8.6.与会人员不得无故缺席、迟到。
9.考评
9.1.依据
1)工作日志/工作总结(5%)
2)工作量与进度/业绩与贡献(40%)
3)技术难度(10%)
4)工作质量(20%)
5)文档质量(15%)
6)综合评价(10%)
9.2.周期
每月一评,作为岗位工资浮动的依据。
见习工程师除了每月一评外,见习期满后还增加一次岗位转正考评。
9.3.细则
每一项指标的评价分为5个等级,最高等级是5,最低是1。
各项指标的得分总和就是本次考评的最终得分。
9.3.1.工作日志/工作总结
参考标准:
工作日志(含工作总结)的完整性,详细性,合理性,准确性。
得分:
等级数×1
9.3.2.工作量与进度
参考标准:
工作日志(或出差报告)和工作进度报告中的内容;解决问题的数目;参与项目的数目,代码编写量
得分:
等级数×8
9.3.3.技术难度
参考标准:
没有以前项目经验可供借鉴;采用了新技术
得分:
等级数×2
9.3.4.工作质量
参考标准:
程序符合公司编码标准;程序可读性;程序缺陷数目;原理图和PCB图;印刷板改版次数;稳定性;可靠性
得分:
等级数×4
9.3.5.文档质量
参考标准:
源代码组织结构;文档制度中提到的各类文档可用性
得分:
等级数×3
9.3.6.综合评价
参考标准:
工作态度;出勤率;外部评价(其他部门、用户等);内部评价(本部门主管、主任工程师、同事等)
得分:
等级数×2
10.培训
10.1.部门内部培训
10.1.1.为了增强对公司现有系统的理解和提高自身开发能力,部门鼓励技术交流和相互培训。
10.1.2.培训主题由部门提议,指定培训教师,或由个人主动申请担当培训教师。
对担当培训教师的人员给予每课时50元的现金奖励,受到好评并可以向公司范围推广的培训内容要追加额外的奖励。
10.1.3.培训尽量不要占用日常工作时间;对放在日常工作时间之外进行的培训视为参加人员的加班。
10.2.外部培训(参见公司相关规定)
开发部管理制度学习签字表
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 开发部 工作制度 V10