研发部管理制度.docx
《研发部管理制度.docx》由会员分享，可在线阅读，更多相关《研发部管理制度.docx（35页珍藏版）》请在冰豆网上搜索。
研发部管理制度
版/次：
A/0
IT部-研发部管理制度
编制：
上海
2014年5月
目录
第一章研发部项目管理制度1
第二章研发部项目评审制度4
第三章研发部项目交付物管理制度8
第四章研发部项目验收流程10
第五章研发部绩效管理制度13
第六章SQA工作流程16
第七章研发部培训管理制度19
第八章研发人员招聘管理制度22
第九章保密制度24
第十章固定资产管理制度25
第十一章研发物品申领制度26
第一章项目管理制度
1、目的：
为规范项目研发、加强项目管理，公司根据企业实际情况和研发产品的特点，特制订项目管理制度，望研发部门遵照执行。
2、范围：
适用于对优通研发部项目研发的管理。
3、职责：
3.1研发部工程师负责对相应模块进行设计开发。
3.2研发部技术主管负责对公司研发过程技术方向监控与技术支持。
3.3优通行政主管负责对公司研发人员行政方向监控与人事工作。
4、程序：
4.1项目流程概述
项目流程项目研发须经过立项、设计、实现和测试等几个阶段。
4.2立项
1）针对研发项目，首先要起草项目立项报告。
2）针对已经签定销售合同的项目发生的研发，作为合同项目研发，不再单独立项。
3）项目只有立项后才允许进行进度研发。
4）项目立项后应获得一个唯一的研发编号，费用报销、研发领料领用等，都使用此编号作为物流控制和财务核算的依据。
5）项目计划报告必须具有项目名称、立项目的、编制、审核、项目周期、预计达到参数指标以及该项目特设指标或者关键技术等相关内容。
4.3设计
1）立项后，项目进入设计阶段。
2）设计阶段由设计承担人完成技术设计报告和测试计划报告，以作成项目计划报告。
3）技术设计报告应说明项目名称、研发系统或设备的需求、总体功能、模块划分等。
4）测试计划报告应说明项目名称、产品功能、测试项目、测试条件、测试方法、测试工期和时间计划等内容。
5）项目负责人应邀请研发部门和公司其他部门相关人员，对设计报告和测试计划报告进行评审。
6）针对没有通过设计评审的项目，须进行重新设计，再组织有关评审。
4.4实现
1）设计评审通过后，进入项目实现阶段。
2）研发人员必须在实现过程中书写相关文档，文档必须有电子形式。
软件实现文档应包括软件功能性说明文档和源代码说明文档。
硬件实现文档包括电器原理图及结构示意图。
3）项目负责人有责任按照项目计划报告，跟踪监督项目的进展情况，按时敦促验收阶段性成果。
4）研发产品由研发人员自行调试，调试过程中必须撰写调试记录。
调试记录应该说明项目名称，编号，调试记录版本号，调试时间，软硬件版本号，调试中发现的主要问题，调试环境，解决方法等有关内容。
5）研发产品确认运行稳定后，由项目负责人组织内部验收。
研发文档应视为研发实现阶段工作量的一部分，不具备研发文档将视为工作没有结束，不组织内部验收。
6）软件功能性说明文档应说明项目名称，编号，软件名称和编号，软件功能，软件功能模块划分，主要功能实现过程，软件主要实现算法。
7）源代码说明文档项目编号，软件名称，软件功能等。
源代码说明文档可以包含在源代码文件中，以注释形式存在。
4.5测试
1）研发产品经内部验收后，进入测试阶段。
2）测试阶段开始后，研发实现人员将研发的产品，以及研发调试记录移交给测试人员。
测试人员按照产品的测试计划报告、研发调试记录，设计测试过程，填写产品测试报告。
3）产品测试报告应该说明项目名称，编号，测试报告版本号，需测试功能，指标，测试方法，测试环境，测试条目，测试结果，结论等。
4）如果研发产品不能通过测试，测试人员应把产品测试报告提交给产品实现人员。
产品实现人员修改软硬件后重新进行调试，相应更新研发调试记录内容和版本号，确认产品合格后提交测试人员再次检测。
如此反复，直到产品通过测试为止。
5）测试人员确认产品达到要求，在产品测试报告的结论栏内签字表示同意，交项目负责人。
4.6产品发布
1）项目负责人拿到产品测试通过的报告后，填写或者委托他人填写产品发布公告和产品发布计划，交公司技术负责人或者授权产品发布人核准，签字发布。
项目负责人与签字发布产品的不得为同一人。
发布公告和产品发布计划需送市场部、生产部和公司有关领导。
2）项目负责人必须在产品发布后一周内，将所有研发文档整理存档。
3）产品发布计划应说明项目名称、编号、产品名称、型号、版本号、产品说明书的完成时间和计划。
产品说明书的完成时间一般应在产品完成后5个工作日内完成。
4.7生产
1）产品发布后，进入正式生产阶段。
2）生产阶段须具备总装图、电器原理图和性能参数要求。
3）装配图应说明产品名称、型号结构件的固定位置、装配顺序、电气连接图、走线固定位置等。
4）生产测试要求文档需要说明针对的产品名称，型号、测试环境和测试方法。
4.8项目调整
1）设计更改
●由于市场或技术原因，需要对项目重新进行设计时，更改人员需填写设计更改申请单，按照立项程序进行审批。
需经公司技术负责人签字同意，报公司总经理批准生效。
●对已经发布的产品进行更改，被认为是一个新的研发项目，按照标准程序执行。
●对尚未发布的产品进行更改，需要更新该项目所有此前产生过的技术文档，已经进行过的评审必须重新进行。
2）项目取消
●出于市场或其他方面的考虑，需要取消某个项目的研发，必须由发起人或者委托人填写项目取消申请表，申请表必须说明项目名称，编号，取消原因。
●研发项目的取消需经公司技术负责人签字同意，报公司总经理批准生效。
●项目取消后，研发助理负责将项目取消通知发送给公司领导层和研发、销售、生产、财务等相关部门。
3）项目暂停
●出于市场或资源饱和原因，需要暂停某个项目的研发，必须由发起人或者委托人填写项目暂停申请表。
●申请表必须说明项目名称，编号，取消原因。
研发项目的暂停需经公司技术负责人签字同意，报公司总经理批准生效。
●项目暂停后，研发助理负责将项目暂停通知发送给公司领导层和研发、销售、生产、财务等相关部门。
5、质量记录：
第二章项目评审制度
1、目的：
主要是尽早发现潜在的问题，尽早纠正缺陷，控制项目整体进程。
2、范围：
适用于研发部项目评审工作。
3、职责：
3.1项目组长协助评审人员进行项目评审工作，并提交评审计划。
3.2评审人员针对项目进行系统评审并撰写评审报告。
3.3评审人员应对评审完成发现的问题进行后续跟踪处理。
4、程序：
4.1评审角色构成因素
评审人员的选择是评审效果的关键，需要考虑以下因素：
Ø项目重要性：
项目重要性是决定角色构成的最重要的因素，先要根据项目的重要性而定。
这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。
Ø项目复杂度：
项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。
笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。
项目组成员的能力成分和水平。
Ø项目组成员的能力成分和水平：
评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。
除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。
应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。
需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。
4.2基本角色职责
Ø评审组长：
制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。
Ø评审人员：
必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
Ø文档作者：
按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
Ø记录人员：
评审会议中记录评审人员提出的问题及相关讨论。
Ø项目经理：
制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。
而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。
4.3文档评审的层次
Ø过程规范：
是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。
适合的评审人员：
QA。
Ø文档规范：
文档成果符合企业或业界已经制定的文档模板规范。
企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。
适合的评审人员：
QA。
Ø文档语法：
文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。
适合的评审人员要求：
精通软件工程、分析与设计方法、建模工具和相关标准。
Ø文档语义：
文档成果表达清晰、无歧义，可以反映系统目标。
所有质量合格的文档（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。
文字与图表应当互相补充说明，以更加清晰。
让别人看得懂，看完后知道下一步该怎么做。
适合的评审人员：
行业业务专家、高级程序员和测试工程师。
Ø文档逻辑：
主要体现需求与设计正确性、一致性，无遗漏、多余或错误。
前后左右考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。
适合的评审人员：
行业业务专家、产品经理和测试工程师。
Ø文档美学：
文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。
需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。
平衡有多个方面，如排版次序更加合理、文字、图形更加精炼并更易理解等。
适合的评审人员：
系统分析与设计专家，以及建模工具专家。
Ø结果优化：
通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。
任何一项设计都可以有许多不同的方案，通过“方案优化”选定一种最好的方案。
适合的评审人员：
系统分析与设计专家、项目经理和产品经理。
4.4文档评审流程
4.4.1评审流程概览和流程图
①确定评审组长。
②制定并发布评审计划。
③准备评审。
④举行评审会议。
⑤改正、跟踪和回归评审。
⑥分析、总结和报告。
⑦归档。
4.4.2确定评审组长
由品质保证人员与项目经理、部门经理论协商，确定项目的评审级别及评审人员角色构成要求，初步确定评审组长人选。
品质保证人员与评审组长沟通，最终确定评审组长。
评审组长充分了解项目相关情况，为制定评审计划做好准备。
4.4.3评审计划
①评审组长制定评审计划（根据项目计划和质量计划）。
②评审组长确定评审对象和评审时间。
③评审组长确定评审级别和策略（形式的组合）。
④评审组长确定评审流程裁减和提交物。
⑤评审组长确定入口条件并通过准则。
⑥评审组长确定回归评审准则。
⑦评审组长制定评审检查表（CheckList）。
⑧评审组长确定评审角色构成。
⑨评审组长根据评审角色构成确定评审人员并成立评审小组。
⑩相关人员（评审人员和项目团队双方）确认评审计划。
评审组长发布评审计划。
4.4.4评审准备
①正式评审前准备：
文档作者向相关人员发布文档。
②评审人员阅读了解文档，争取发现大部分问题。
③文档作者解决大部分发现的问题。
④评审组长确定会议地点、环境、设备和所有材料。
⑤评审组长确定人员职责和会议议程。
⑥评审组长确定评审开始条件成熟。
⑦评审组长通知相关人员到会。
4.4.5评审会议
①主持人（评审组长）宣布会议议程、人员职责和会场纪律。
②文档作者介绍工作成果，对评审人员的疑问进行必要的解释。
③评审人员对不解之处提出疑问，指出问题或缺陷并说明根据。
④文档作者与评审人员讨论缺陷的真实性，分清缺陷性问题和建议性问题，讨论确定是否需要按照评审人员的要求进行改进。
一般不涉及为节省时间改进方案或错误的纠正方案。
4.4.6评审记录
①正式评审应当记录有共识的问题或缺陷，也要记录有争议待解决的问题。
使评审工作文档化，便于跟踪最终解决。
②总体记录：
包括项目名称、系统名称版本号、日期时间、主文档名称、附文档名称、文档版本号、作者、评审类型（首次、回归、部分和阶段）、评审人员和评审结论。
③缺陷记录：
包括缺陷编号、提出者、章节／页码、缺陷描述、缺陷类型（严重、一般和建议）和承诺改正时间。
④验证记录：
全部打勾的CheckList，说明CheckList所列的工作都已经做完，所列的内容都已经评审完，确保工作的完整性。
4.4.7评审结论评审结论包括如下内容：
①是否需要修改？
这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。
②项目组确定是否接受修改要求？
这是针对具体的一条意见或建议。
有些问题可能是误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。
—如不接受修改要求，项目组给出不修改的理由。
—如何处理？
是否需要进行回归评审？
—总体结论：
合格或不合格。
—确定的修改责任人和跟踪责任人。
—确定的回归评审时间。
—是否都认同评审结论？
如果需要做得更正式一些，可以要求相关人员签字表示同意评审结论，签字。
4.4.8跟踪与总结
评审中发现的问题的后续跟踪是改正错误并消除缺陷的有效措施，应当有专门的负责人进行后续跟踪确认错误都已改正，根据结论必要时回归评审。
评审组长分析评审数据并总结经验。
②评审组长发布评审记录与数据分析报告。
③管理人员应当防止评审数据被不恰当地使用，如果使用评审数据来对个人进行绩效评价，将会给以后的评审工作造成障碍，使评审各方不能放开进行评审。
④评审组长进行工作总结，工作总结很有必要，有利于对项目或过程的改进。
⑤评审组长提交各类评审报告，有关领导批准发布通过的文档。
4.4.9材料归档
评审材料归档是项目配置管理工作的一部分。
新建项目，记载配置管理工具中为此项目建立一个目录，并建立下列子目录。
①待评阅态：
文件放入此目录后会自动通过邮件通知需要评阅的人员，全体评阅人员评阅完毕，也会自动通过邮件把意见通知文档作者并实现到期自动提醒功能。
②待评审态：
文件放入此目录后会自动通过邮件通知需要评审的人员，全体评阅人员评审完毕，也会自动通过邮件把批准或拒绝的意见通知文档作者并实现到期自动提醒功能。
③受控态：
评审批准后自动转入受控态并发布自动邮件。
④签出态：
为了修改而版本升级，当文件签出时放入签出态。
修改后的文档可能签入到待评阅态、待评审态或直接到受控态，但文档版本已经升级。
⑤产品态：
项目结束后受控态的文档自动归到产品态。
5、质量记录：
评审计划、评审报告
第三章项目交付物管理制度
1、目的：
为规范本公司研发部技术文件的管理，确保文件编制的正确性、完整性，特制订本制度。
2、范围：
适用于公司研发部门项目完成后的交付物的管理。
3、职责：
3.1项目组长及成员应对所研发项目的交付物列清单逐一交付。
3.2办公室为研发部技术文件设立档案保管，借阅情况统一进行统计。
4、程序：
4.1技术文件的编制、审核、批准
1）技术文件包括：
a）产品设计图纸；
b）作业指导书；
c）设计相关书籍、光盘等；
d）技术档案和技术资料；
e）未打印出图的尚在计算机里的图纸资料；
f）发放到各部门的技术文件；
g）实物样品等研发部相关文件。
2）技术文件的技术要求和数据等必须符合国家相关标准和规定要求。
3）技术文件由技术开发部等相对应部门编制，研发部应对技术文件的准确性、合理性负责。
4）研发部部长负责技术文件的审核。
5）总经理负责技术文件的批准。
6）技术文件的编制必须严格保密。
7）技术文件应保证标题栏中的编号、名称、日期、审核、批准等栏中签署齐全，签署不齐全的技术文件无效。
4.2技术文件的管理与应用
1）技术文件的发放：
a.技术文件在发放至生产车间之前，必须加盖“受控文件”章，到研发部处登记，填写【技术文件领返记录表】，签字领出。
b.技术文件的发放按生产计划进行，定期发放的生产用文件由研发部统一下发和更换。
研发部门必须保证下发的工艺的完整性和有效性，同时保证下发到车间主任、生产指导、检验等部门的工艺应一致。
2）技术文件的保管和使用：
a.研发部的技术文件应长期并分类保存，管理要科学系统，能有效控制，确保各相关部门都能得到有效的版本，防止作废的技术文件误用。
作废的技术文件必须经常研发部部门鉴定且研发部部长批准后销毁。
b.本公司的技术文件，由研发部管理。
确保所保管的技术文件不受潮、不霉烂、不受损、不丢失。
c.纸质技术文件或光盘技术文件等收存到资料柜内保管，资料柜钥匙由研发部部长负责保管。
本单位有关人员可以查、借阅。
借阅技术文件应凭技术开发部部长批准的【借阅申请单】向研发部借阅。
用完及时归还，并保证文件的完整性。
d.技术文件是公司进行生产和各项管理工作共同的技术依据，必须加强管理，各种技术文件的登记、保管、复制、收发、注销、归档和保密工作，保证技术文件的完整，准确清晰、统一等。
e.签字领出技术文件人应负责将领出的文件收回，交研发部部长存档。
f.每种技术文件，研发部应完成技术资料整理，并做备份、存档。
g.本厂所使用的研发部技术文件一律由研发部统一保管，统一建档并逐一登记。
3）技术文件的更改
a.产品投入生产时，技术科应及时提供相应的工艺作业指导书并确保无误。
生产部如发现操作时，有不妥当的方面及时与技术科主管沟通解决。
b.下发后的技术文件如需更改，研发部需要下发《文件更改申请单》，各相关部门必须据通知单要求做相应更改。
涉及安全性能的图纸更改后，须由研发部组织重新审核并备案。
更换的技术文件要有标记，并要有记录。
c.技术文件修改前，负责修改部门要提出修改理由及具体内容，交研发部部长审批。
d.修改后的技术文件必须重新履行会审、会签及批准手续，填发《文件更改申请单》。
4）技术文件的保密
a、任何部门、个人不得擅自打印、复制公司技术文件，不得以电子文档等形式在网上传递或者用移动硬盘、U盘、软盘等拷贝出。
因工作需要必须打印或复制时，经办人提出书面申请书，开发部部长签字批准后方可通过打印、复制、拷贝。
b、为了保证技术资料的保密性，除按正常程序办理外，任何人不得私自向外人转让和借出技术资料，一经发现要按公司所签署的《保密协议》给予严肃处理。
c、员工用于工作的计算机未经主管批准不得随意拆开，计算机硬盘中的资料属公司机密，硬盘不准任何人私自带出公司。
若计算机出现故障，需研发部部长指定专业人送修，并保证硬盘中资料保密性。
d、技术科及其他使用、保管技术资料的部门或个人，应注意保密，严禁将技术资料带出公司，或提供给其他公司。
1）技术文件的销毁
a、由于新技术的日新月异，越积越多的技术文件会占据不必要的资源，故有的技术文件需要销毁和清除，对回收的技术文件由技术部门统一管理。
b、需要销毁的研发部技术文件，研发部部长会同有关技术人员一起仔细校对核实，然后将销毁理由与销毁文件清单上报研发部部长，由研发部部长签署“同意”后，方可销毁。
c、普通技术文件须保存3年以上，重要技术文件须保存5年以上，以方便以后的产品技术改造。
因各种原因，导致某种产品不再生产，或产品改型，使原有技术资料报废，由研发部收回，加盖“报废”章，并专项保管。
5、质量记录：
交付物清单
第四章项目验收流程
1、目的：
为规范公司项目验收工作流程。
2、范围：
适用于公司验收项目管理。
3、职责：
3.1验收小组成员严格按照此规范对项目进行验收。
3.2项目组长及成员应配合验收小组成员做好项目验收工作。
3.3办公室应对验收情况和结果进行存档处理。
4、程序：
4.1验收流程图：
由于IT项目验收一般均比较复杂，因此，一般将IT项目的验收划分为四个阶段：
验收准备、初步验收、最终验收、报告总结。
（见划分请参见：
IT项目验收流程图）
4.2验收准备
验收准备阶段主要是根据项目的情况组建验收组织，并确定验收方式、验收内容、标准以及验收条件等。
1）成立验收小组。
验收小组的主要组成为使用部门、信息技术部、招标部门、财务等部门，该项工作需要领导的参与和批准，另外，对于金额比较大的项目，有条件也可以请股东代表参与。
2）确定验收策略。
验收小组根据项目的特点确定项目验收的方式，即是否需要分阶段验收，完成验收阶段的划分，并制定相关的验收计划，一般对于比较复杂的项目均需要划分阶段进行初步验收，而且阶段的划分也需要与供应商进行沟通和确认。
3）确定验收内容和标准。
根据前面确定的验收策略明确各阶段验收的条件、需要验收的内容、验收通过的标准，以及需要提交的资料清单等，其中值得一提的是验收内容包括时间进度的验收项目。
4）领导审批。
由领导审批验收小组确定的验收阶段和验收内容以及标准等是否合理。
4.3初步验收
初步验收主要是完成软硬件系统的初步运行情况，IT项目可能涉及硬件设备的验收，也可能涉及软件系统的验收，也可能同时涉及软件和硬件的验收，由于对于机房装修这样复杂的项目，涉及到几个硬件子系统和软件子系统的验收；对于硬件系统的验收，存在两个验收步骤，在设备到货后需要验收设备到货情况，在调试完成后需要进行设备试车验收（试运行），一般付款条件为试车验收通过，不是到货验收通过。
1）验收申请。
当供应商认为符合验收条件后会提请进行验收。
2）检验验收条件是否合格。
验收小组接到供应商的验收申请后，审查是否符合验收条件。
3）供应商进行整改。
如果验收小组认为不符合验收条件，将要求供应商进行整改，供应商根据验收小组提出的整改意见进行相关的整改，整改完成后再次提请验收。
4）验收类型的判断。
验收小组会根据项目的性质，分别按照软硬件系统进行初步验收。
5）硬件设备到货验收。
当硬件设备到货后，供应商会提请进行到货验收，验收小组将根据合同和验收内容进行设备的品牌和规格的检验，查看设备是否完整无缺，并记录设备到货时间是否符合要求。
6）报关单、保修卡和说明书等校验。
验收小组检验设备的保修卡和说明书等资料是否准确无误，另外，对于进口设备需要检查设备的报关单是否正确和有效。
7）集成调试。
到货验收合格后，供应商进行设备的集成调试工作。
8）试运行验收。
俗称试车验收，在供应商完成设备的集成调试后将提请进行试运行验收，验收小组需要根据验收内容逐项进行相关验收。
9）软件系统功能验证。
软件使用部门根据需求或验收内容和标准，对软件系统功能进行详细验证测试，验收小组监督和汇总测试情况。
10）软件系
升级会员 