研发部管理制度Word格式.docx
《研发部管理制度Word格式.docx》由会员分享，可在线阅读，更多相关《研发部管理制度Word格式.docx（37页珍藏版）》请在冰豆网上搜索。
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、质量记录：
第二章研发部绩效管理制度
通过考核评定实行相应的绩效处罚，并不断的发现管理的工作不足之处，调整全公司的工作方向和管理目标。
原则：
以奖为主，以罚为辅，重奖轻罚，奖罚分明。
适用于对本企业研发部人员绩效方面的管理。
3.1研发部行政主管负责制定研发部人员绩效考核指标的修改和建立。
3.2研发部员工应遵循此制度条款配合公司绩效考核工作。
3.3办公室应配合研发部做好绩效考核相应工作并对考核结果进行整理归档。
4.1宗旨
考核制度贯彻于研发工作全过程中，利用绩效和奖金相结合的报酬机制，鼓励积极，鞭策落后，提高产品开发效率和合格率，减少失误，降低开发成本，增加公司产品的市场竞争力，同时调动每位研发人员的工作积极性，努力提高工作水平，统一员工的工作努力方向，推动公司的持续快速发展。
4.2基本原则
1）结果考核与行为考核相结合
2）考核者必须依据员工实际表现和工作事实进行评价。
3）公司成立技术开发评审小组，小组成员由总经理任命。
4）考核必须公开考核流程、公开考核指标，坚持公正、公平、公开的原则，考核结果由考核双方共同签字确认。
5）考核执行人必须充公了解员工在考核期内的工作内容、工作过程和工作效果。
在双方平等沟通的基础上展开考核工作。
4.3细则
1）按照各人负责的工作类别不同，考核类别分为“优秀、良好、合格、不合格”。
2）电路设计：
视产品复杂性及任务的完成情况，以绩效考核表为准。
3）结构设计：
4）硬件设计：
5）软件设计：
6）文秘及后勤：
及时、准确、妥善的将设计师的文件归档、分发、收取，对需要打样的产品落实追踪到位，准时是考核的主要条件。
4.4考核对象
1）试用期及实习期员工不参与此项考核
2）已转正的员工则根据工作情况，分为非技术类及技术类进行考核。
3）部门经理级人员（含部门副经理）不参加此项考核，由公司统一进行部门经理综合考核评定。
4.5考核周期与时间
1）实行半年度考核；
每半年考核一次。
其中每年的6月份考核上半年的业绩，每年12月份考核下半年的业绩。
2）考核正式开始前十日部门开始进行考核，两个工作日提交办公室汇总呈评审小组最后得分，三个工作日评审小组出具考核结果，由办公室下达考核结果给部门经理，五个工作日内完成绩效面谈。
4.6实施
1）考核的依据：
设计计划书中的进度规定和设计要求。
2）考核方法：
综合评分，按照公司绩效考核表中内容进行考核。
3）评分标准：
分为自评和上级领导评价，根据分值加权求得最终分数对应相应等级。
4）每次考核完成汇总员工评分并分出等级，并根据公司相应规定进行鼓励与批评谈话。
5）公司设置独立员工工资体系外的考核资金，每季度得分超过100%的员工，每增加1%奖励基本工资的10%，最高不超过其基本工资的200%。
有特殊贡献的员工，公司予以奖励，由董事会审批。
6）绩效考核流程图：
7）
4.7考核体制
考核对象
初评
汇总部门
复评
最终核定
技术人员
研发部门
办公室
评审小组
副总经理
部门职员
/
1）由员工填写本季度主要工作项目及业绩，给考核者相应参考数据。
2）部门评定：
由员工直属上级对员工个人本季度各考核项目做出综合评分。
3）评审小组对其考核的结果做复评。
4）副总经理进行最终评定。
4.8绩效沟通与改进
1）每考核完成一次部门经理至少需和员工进行一次绩效面谈，共同确定绩效计划，讲解员工优势和需要改进的绩效，共同分析与实际结果存在差距的原因，达到组织绩效与个人绩效目标一致。
2）各部门可根据工作需要增加面谈次数。
3）面谈方式为：
以正式的、一对一、面对面的方式进行。
4）每次考核完成要进行绩效考核情况调查，分发调查表进行无记名调查，针对提出的问题进行改进。
4.9考核申诉
考核申诉是为了使考核制度完善化和在考核过程中真正做到公开、公正、合理而设定的特殊程序。
1）参加考核的任何员工对评估结果拥有申诉的权利，部属与直接主管接到考核内容和结果后，如有异议，可先向直接主管提出申诉，由直接主管进行协调；
如直接主管协调后仍有异议，可向办公室提出申诉，由办公室进行调查协调。
2）考核申诉的追诉时限至考核当月结束为止。
4.10评估资料的保管
1）各部门部门经理指定专人对员工所有的评估资料进行集中保管，考核表必须以电子文档形式及书面形式各保留一份，电子文档由部门及办公室各留存一份，书面文档由办公室作为人事档案留存。
2）季度评估表作为员工的人事档案由行政部统一保管。
3）除管理人员因工作需要可查看员工的评估资料外，其他员工不得随意翻看、查阅。
4）任何接触到考核资料的人员都有保密的义务，不得散布、传播。
4.11附则
1）本制度由公司管理部门负责修订而成，解释权归办公室。
2）整体考核进程由办公室负责推动，各相关部门协助完成。
3）本制度是公司绩效考核的重要制度，每一位员工均可对其不完善之处向办公室直接提出相关建议，被采纳的建议将在制度中及时修订。
4）本制度执行后，与本制度有抵触的规定或条款以本制度为准。
绩效考核培训资料、绩效考核计划、绩效考核表、绩效考核调查表
第三章SQA工作流程
为加强项目监控体质管理，监督研发过程，对项目研发进度进行全程质量监控。
适用于研发部项目过程的监控管理。
3.1SQA项目小组成员按分工监控项目过程并及时上报质量情况。
3.2项目组长成员应配合SQA的检查和监督。
4.1目标：
Ø
遵循《软件质量保证计划》进行软件质量保证活动
客观地验证软件开发过程和软件产品是否遵守可用的标准、规程和要求
确保将软件质量保证的活动和结果通知受影响的项目组和人员
高层管理者关注在软件项目中不能解决的偏差事件和不合格项
4.2SQA活动的策略
当SQA刚切入项目组时，SQA首先就要掌握项目组的一些基本情况，主要包括项目经理的能力,项目的规模，项目工期，客户对进度、质量的要求，项目组成员情况，项目组织架构情况。
其中最关键的是要看项目经理的能力情况。
１）PM能力欠佳，则SQA的工作就是全程跟踪项目，审计是重中之重。
２）项目经理的能力强，则SQA的主要工作可以划分为两部分，一部分是对一些重点的过程和产品进行审计，另一部分是优化我们的过程，流程，对我们的发现的一些问题或缺陷进行分析，改进我们的过程。
4.3具体活动：
1）SQA参与制定计划
SQA参与制定计划包括SDP和阶段计划，在SDP活动中，SQA主要是参与到软件过程的剪裁、复审估算、参与评估风险等。
然后，SQA参与复审SDP，其目的，除了熟悉项目的计划外，还需要复审看是否SDP与纳入项目的客户的需求一致，计划能否满足客户的需求的，在SDP修正中，涉及到上述内容的，也需要SQA参与。
然后，SQA也会参与阶段计划的制定，主要是复审阶段计划是否满足阶段的目标。
2）SQA参与复审纳入项目的需求
此时SQA主要是作为复审者的角色，复审纳入的需求描述是否清晰、一致、需求的可行性等。
3）SQA制定SQA审计计划
在制定计划的同时，SQA也需要制定SQA审计计划，在制定SDP的时候，SQA制高层的审计计划，主要是计划有那些内容需要SQA审计的。
然后，在制定阶段计划的时候，SQA需要制定具体的审计计划，包括每次审计的时间，审计的对象等。
4）SQA参与进度复审或里程碑复审活动
SQA在参与进度复审或里程碑复审活动中，主要是一方面了解项目的进度，另一方面，复审项目在进度复审中采取的一些修正行动的时候，是否满足客户的需求，是否可行等，而在里程碑复审中，则复审项目当前的状态是否满足里程碑的标准（CriteriaofMilestone），是否达到里程碑的目标。
5）SQA审计
另外，SQA的主要活动是按照制定的SQA审计计划对项目进行审计，审计的内容包括过程审计和工作产品审计。
过程审计主要是审计项目开展的软件活动是否和计划、与OSSP一致，工作产品审计主要是审计工作产品是否满足标准和约束条件。
6）SQA阶段总结
由于公司很多项目都是采用迭代模式的开发，项目开发周期较长，所以有必要在项目某个阶段结束的时候，对SQA在这个阶段的活动进行一个总结，主要是对一些经验教训进行分析，找出这些问题背后的原因，提出一些可行性的解决方案，目的是为了提高质量保证的水平。
7）跟踪问题处理
SQA应跟踪问题处理过程，直到问题解决。
跟踪的问题包括日常发现的产品问题、过程问题、项目风险、评审发现的问题、测试发现的问题等。
如果不能和项目组就解决方案达成一致，可向公司高层反映。
8）度量和报告
SQA应善于根据过程规范和经验发现项目运行中的问题，并做到紧急问题、重要问题
随时汇报，其它问题周期性汇报。
SQA需要随时收集数据并保障数据的有效性、真实性。
定期汇总数据、统计分析并产生度量报告。
SQA应协助项目组和SEPG针对不良趋势和问题采取纠正或预防措施。
9）质量推进
质量推进主要包括提高全员的质量意识和推进、解释过程的执行两个方面。
这项工作需要在日常工作中一点一点地、坚持不懈地实施,这样做的目的是为了营造公司的一种质量文化氛围,理解和支持SQA的工作。
10）过程制定
如果项目或组织需要制定过程规范，SQA应组织相关人员来完成过程制定工作。
一般情况下，过程制定应由遵守和执行该过程的人员负责。
所有制定的过程都必须经过评审，并由SQA检查执行情况。
11）过程改进
过程改进是一项长期的任务。
SQA应注意随时发现、听取过程执行中问题和改进工作的方法，并进行阶段性的总结（比如质量报告等），以不断改进过程，提高过程能力。
12）学习和研究
SQA要不断学习和研究，尽量保持与领域最新的知识、方法同步，找出提高产品质量和工作效率的方法与过程。
学习的内容主要包括管理领域和开发领域。
管理领域包括质量管理（TQM、ISO9000、CMM、RUP、MSF、XP等）、软件度量（PSM、GQM、SPC、SixSigma）、项目管理、配置管理等。
开发领域包括需求工程、设计、编码、测试等各阶段的开发和管理方法。
13）质量培训
项目或组织需要时，SQA需要向相关人员进行质量管理方面的培训或咨询
4.4SQA审计工作指南：
SQA工作的很重要一项就是审计，SQA审计工作的目标是验证项目组实际执行是否与项目计划相符合，执行的步骤是否与公司规定相符合，及时发现项目存在的问题，并提交问题报告，跟踪直至问题得到解决。
4.4.1SQA审计工作的各个阶段：
可以将SQA审计划分为各个阶段：
1）审计任务计划阶段：
审计任务的计划是SQA计划中的一部分，应该根据每个项目的特点进行不同的考虑，以安排审计任务。
主要的依据有几点：
根据项目的风险安排审计任务的重点，根据项目计划的进度安排组织审计任务的时间，根据审计对象的不同考虑审计方法；
2）审计任务执行阶段：
审计任务应该按照SQA计划来执行，并根据审计对象的不同采取对应的审计方法；
因为实际的审计的执行需要兼顾项目的实际情况（包括人员、进度），因此要做好SQA审计状态的记录，及时跟踪审计任务的执行情况，出现审计任务与SQA计划的出入时，应该进行计划变更；
3）审计问题的提出阶段：
在审计中发现问题时，应该首先与项目相关的工作人员沟通，明确问题，同时记录SQA问题清单，并知会项目PM；
问题应该得到项目组的认同，问题说明应该清晰，当问题不能够明确时（不能认同、确定），需要报请SEPG或者高层经理确认。
发现的问题一般应该得到及时的处理，当问题不能及时解决时，应该提交SQA的问题报告，问题报告中需要明确问题的责任人，以及计划解决时间；
4）审计问题跟踪阶段：
对SQA提交的问题，需要对其状态进行跟踪，保证问题能够得到解决，对于解决时间超出计划时间的问题，应该在每周的报告中提交给高层经理。
4.4.2SQA审计方法：
审计方法根据审计对象的不同，可以分为：
项目活动审计，和项目产品审计。
1）项目活动审计是根据项目计划，到达对应的项目活动执行时，SQA人员切入到项目中，通过与项目组沟通，了解项目活动的执行情况。
具体的了解方式可以有多种，如：
与项目组直接的沟通、通过活动的记录文档了解活动的进展、直接参与项目组的活动等；
方法的选择取决于活动的类型以及项目的具体情况，采用什么方式以达到了解项目活动实际情况为目标。
2）项目产品审计，主要是对项目的工作产品进行审计，项目的工作产品是否合格包括两个方面：
1、满足客户以及公司对产品的要求，一般要求符合工作产品的模板、标准，其中客户的要求一般都会明确在项目纳入的需求和相关的计划中；
2、项目产品的合格也是由流程来保证的，产品的开发过程应该按照计划得到了必要的复审和评审。
审计产品的时机一般是在产品提交后进行，但是SQA也应该根据工作产品的特点，注意安排产品制定、开发当中的审计，以期及早发现问题。
4.5报告机制
1）周报：
把一周来SQA活动发现的问题进行汇总并加以简要的分析，发送高层、项目组有关负责人、质量部负责人、SEPG
2）上报项目经理：
对一些比较紧急的问题应立即报告给PM，如果能达到一致的情况下,要求落实问题的解决,
3）上报高层：
如果发现了问题，不能与pm达到一致的话，上报高层
4.6参与的其它活动
了解项目成员每天的工作情况
促进项目关系人员之间的沟通
参与风险的识别，跟踪管理
量化工作
4.7SQA工作流程图
SQA计划、审计报告、状态报告
第四章项目评审制度
主要是尽早发现潜在的问题，尽早纠正缺陷，控制项目整体进程。
适用于研发部项目评审工作。
3.1项目组长协助评审人员进行项目评审工作，并提交评审计划。
3.2评审人员针对项目进行系统评审并撰写评审报告。
3.3评审人员应对评审完成发现的问题进行后续跟踪处理。
4.1评审角色构成因素
评审人员的选择是评审效果的关键，需要考虑以下因素：
项目重要性：
项目重要性是决定角色构成的最重要的因素，先要根据项目的重要性而定。
这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。
项目复杂度：
项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。
笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。
项目组成员的能力成分和水平。
项目组成员的能力成分和水平：
评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。
除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。
应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。
需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。
4.2基本角色职责
评审组长：
制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。
评审人员：
必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
文档作者：
按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
记录人员：
评审会议中记录评审人员提出的问题及相关讨论。
项目经理：
制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。
而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。
4.3文档评审的层次
过程规范：
是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。
适合的评审人员：
QA。
文档规范：
文档成果符合企业或业界已经制定的文档模板规范。
企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。
文档语法：
文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。
适合的评审人员要求：
精通软件工程、分析与设计方法、建模工具和相关标准。
文档语义：
文档成果表达清晰、无歧义，可以反映系统目标。
所有质量合格的文档（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。
文字与图表应当互相补充说明，以更加清晰。
让别人看得懂，看完后知道下一步该怎么做。
适合的评审人员：
行业业务专家、高级程序员和测试工程师。
文档逻辑：
主要体现需求与设计正确性、一致性，无遗漏、多余或错误。
前后左右考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。
行业业务专家、产品经理和测试工程师。
文档美学：
文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。
需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。
平衡有多个方面，如排版次序更加合理、文字、图形更加精炼并更易理解等。
系统分析与设计专家，以及建模工具专家。
结果优化：
通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。
任何
升级会员 