研发流程问题整理5篇

第一篇：研发流程问题整理

林小池

测试：

1、开发项目计划变更通知不到位，导致测试人员从其他项目剥离后无任务安排；——项目变更通知不到位

2、测试组处于被动告知，个别项目需求测试内容是与开发多次交流后得知，需求与开发内容脱节；——项目需求开发过程设计发生变更甚至推翻原有方案

研发：

1、能够直观获取了解前后版本修改内容的对比，便于更快确认修改的内容；

产品：

1、需求既定的情况下，并且经过内部开发技术评审，在时间允许的情况下的开发内部变更都必须互相知晓，保证开发过程中产品需求与用户真实需求的落实的一致性。

2、评审会议是内部明确需求的会议，不是产品的独角戏，所有与会者必须高度的熟悉需求及方案，评审通过后，原则上不允许变更；

3、希望研发内部也能尽量有详细开发文档的留存；

4、研发在熟知需求，开发完成之后要求自测，测试组能有一定的决策，并能对开发提测内容有初步用户体验，对不符合使用习惯或业务逻辑有偏差、样式有区别原型的功能需求提出整改建议。

5、在有产品人员出具的需求文档中，应该以需求文档为业务文档为用户需求，并以之为蓝本，进行开发，研发进行不对该需求中的方案及逻辑、规则进行随意变更；

陈莹莹

1、小池展示的原型文档相对完整，且有益于项目交接，但此文档单次输出时间较长，是否能适用于我们现有的开发流程？对开发和测试的工作是否有很大的推进作用？

2、如何解决项目开发时间紧的情况下保证开发流程的完整性？

3、如果解决开发与测试在需求评审过程中的主动性？

陈家辉

1、对已有系统业务细节无法很好的掌握，一个是历史的需求文档缺失或者记录的不够详细，第二个是代码那边的提交记录，好像代码迁移之后就没了，一些不明确的改动不知道是因为哪个需求改动的 张夏胜

1、需求评审过程中，较难的发现细节问题所在，会出现由开发提起需求变更，有时没有通知测试，造成信息不对称。

2、研发过程中，对外的对接工作出现外部责任不明确，导致研发过程出现等待和返工现象。

3、多人提测会出现版本冲突和遗漏现象。

4、WebApp开发过程中，如果以“浏览器+web工程”的方式很难对应将来客户需求和用户体验，需终端开发人员配合，改进这种搭配方案。

5、需求评审时，测试人员参与时，可以适当的提测改进意见，包括模块命名，按钮命名，用户体验等，不要在开发提测后，出现较多的建议性bug，或者在需求评审时，也动动脑筋，想想这些改动会影响到什么地方，是需求和开发没有想到的陈君耀

测试组存在的问题与解决建议

测试组存在的问题如下: 1.测试需求不明确，导致测试过程经常走弯路或者多花时间。2.工作环境太沉闷，没有学习与提高的动力。3.测试项目太单一，工作过程没有团队的感觉。

4.测试学习不明确、经验不足，没有准确的提高方向。

5.测试方式太保守、测试知识太局限，不敢或者不想接触新事物。6.测试内部沟通太少，导致成员不敢表达意见与问题。

7.项目测试安排不合理，导致参与者会测试部分模块，对项目熟悉较慢。8.测试组没有一个团队凝聚力，没有一个团队的意义（散兵游勇）。9.提测邮件的优化

针对以上问题解决建议

1.测试需求不明确，导致测试过程经常走弯路或者多花时间。

解决建议如下：

1.建议项目经理与开发人员（需求源头），先精确分析提测需求的内容与测试修改点。

2.一个项目有多个开发人员，每个开发人员只了解自己负责的开发需求，有部分开发人员不了解整体需求。（建议项目经理与项目开发人员增加沟通、建议项目中几个开发参与者增加需求沟通）

3.测试人员在测试需求不明确时主动发起需求评审，反向推动。

2.工作环境太沉闷，没有学习与提高的动力。

解决建议如下：

1.优化工作环境，测试全体成员工作过程尽量少发出“叹气”语言。

2.工作过程控制沟通音量，不建议有太大的情绪波动和瞬时高8度的音量。

3.建议每个固定（1~2）个时间进行全体休息（5~10分），主要目的有3个（缓解工作压力、增加所有成员的沟通机会、整调工作状态）。可以先从测试组试点。

4.组建学习小组，定期更新一些专业知识与测试技能。学习小组已经组建，目前学习小组负责人：邱珊珊。

3.测试项目太单一，工作过程没有团队的感觉。

解决建议如下：

1.先执行1岗双人制度，花半年时间让每个人符合要求

2.定期进行各项目内部参与者培训（时间：半年）

3.定期进行软件测试与产品测试的交互培训（时间:1年）

4.2018年培训方向如下：1.提高沟通能力，提高所有成员个人组织能力、2.提高所有成员对项目深入了解、3.提高所有成员的测试能力（测试方法、测试工具、测试技能）、4.引进自动化与性能测试。

4.测试学习不明确、经验不足，没有准确的提高方向。

解决建议如下：

1.针对所有成员历史成表现进行能力分析，给每个所有在2018年定制不同的目标（可以完成的目标）

2.测试组工作2年以下或者测试新人，当前工作状态就是测试机器人，测试过程没有太多的工作思考与提高方向。各项目负责人工作安排需要调整，给新人与参与者经常做出不同的调整，让所有人尽快了解整个项目系统。（正在引导）

3.所有成员要主动发出疑问（正在引导）

5.测试方式太保守、测试知识太局限，不敢或者不想接触新事物。

解决建议如下：

1.当前软件测试与产品测试互相不了解，在测试过程遇到对方测试知识点就要寻求帮忙。在2018年需要打破这个格局，增加两种测试的交流。

2.优化测试流程、尝试各种测试方法缩短测试时间并提高测试质量。（如下：性能测试、比较测试、安全测试、极限测试等等）

3.精确制定学习小组培训与学习方向，增加日常工作以外的测试知识。

6.测试内部沟通太少，导致成员不敢表达意见与问题。

解决建议如下：

1.固定时间开展例会活动，例会主要内容：项目完成情况、日常工作中的问题、个人组织与分享（主要提高成员组织、沟通、表达能力）

2.不定期开展学习小组活动，由邱珊珊来组织。

3.总结测试中未知或者无法解决的问题，组织资深开发人员进行讨论。

7.项目测试安排不合理，导致参与者会测试部分模块，对项目熟悉较慢。

解决建议如下：

1.各项目测试负责人或者测试主管定期考核与分析项目参与者测试水平。

2.各项目测试负责人每个月调整一次参与者工作内容，让所有参与成员尽量熟悉项目。3.参与者在测试过程发现测试阻碍或者测试盲点，需要主动提出问题。项目测试负责人与测试主管第一时间介入处理。

8.测试组没有一个团队凝聚力，没有一个团队的意义（散兵游勇）。

解决建议如下：

1.组织测试组成员定期学习与论讨 2.组织测试组成员定期工作外活动

3.测试主管每个季度分析所有成员工作状态与工作环境

4.测试主管合理的安排工作，减小各项目加班情况、平衡每个人的工作量、提高成员之间工作交流机会。

9.提测邮件的优化

优化建议如下：

1.开发与项目经理提测邮件：1.收件人：项目测试负责人、项目所有参与测试成员；抄送人：项目所有参与开发人员与项目相关需要知晓人员；2.提测内容：提测需求内容、需求对应开发人员、建议测试重点、需求预估截止日期等等。

2.测试结果通知：1.收件人：项目经理、项目所有参与开发人员；抄送人：项目所有参与测试成员与项目相关需要知晓人员；2.提测内容：提测需求内容、参与测试成员负责那部分测试、本次测试重点、测试隐患、测试结论、本次测试过程中遇到的问题（需求协调、缺少人员、开发不配合、测试资源不足等等）

第二篇：研发流程控制

饮料研发控制程序

1.目的

对饮料研发全过程进行控制，确保研发的饮料能满足国家标准及顾客的要求。

2.适用范围

本程序适用于饮料的研发和饮料的改进活动。3.职责

3.1饮料研发组负责编制并且监督执行饮料开发计划，负责饮料开发全过程的组织、协调和管理。

3.2 品管部协助进行研发过程中所需的饮料检测工作。

3.3 总经理负责产品立项，负责主持产品鉴定并批准产品鉴定报告。3.4 与饮料开发有关的其他部门要积极参与饮料的开发工作。4.作业程序

4.1 饮料研发的策划

4.1.1饮料研发组策划人员收集、分析各类市场信息，在此基础上，提出产品概念，填写“饮料开发建议书”，报生产副总批准后，将相关资料存入产品储备库，没有通过批准则重新开始策划。

4.1.2饮料研发组将通过审核的产品概念报市场部进行审核，没有通过则此饮料研发停止进行，重新开始策划工作。

4.1.3市场部通过的产品概念，由饮料研发组组长组织编写“饮料开发计划书”，经饮料研发组成员讨论后，产品研发工作开始实施。

4.1.4 饮料研发组组长负责小组内成员的职责及工作安排，负责做好饮料开发各阶段的组织和协调工作，负责饮料开发全过程的跟进和监督。

“饮料开发计划书”应随着饮料开发的进展适时进行修订。

4.1.5 饮料研发组组长在组织编写“饮料开发计划书”的同时，应编制“饮料开发费用预算表”。

4.1.6 饮料研发组组长要做好饮料开发各阶段的组织和协调工作。4.2饮料研发的输入

4.2.1饮料开发任务书的编制 饮料研发组组长根据 “饮料开发建议书”等资料编制“饮料开发任务书”，“饮料开发任务书”应明确规定对饮料开发的要求，内容可包括：

（1）饮料感官特性：包括气味、口味、质地和外观特性（就是通常指的色、香、味、状态）等。（2）饮料营养特性：营养素、营养成分的种类和性质。（3）饮料原辅材料的要求。（4）饮料的安全卫生要求。（5）饮料的保质期限要求。（6）饮料的价格要求。

（7）包装、运输、贮存要求。（8）适宜的消费者。（9）销售方式。

（10）相关的法律法规和标准的要求。（11）环保要求。

（12）类似饮料的信息以及饮料研发所必需的其他要求。4.3 实验室阶段的研发——配方开发、样品试制及评审

4.3.1饮料研发组进行饮料样品试制，并拟制出《饮料配方》。试制时，要把原辅料成分、比例、工艺参数、试制设备记录在“样品试制记录表”上。

4.3.2饮料研发组组织有关的职能部门对配方、样品进行评审（评审前可让评审人员品尝饮料样品）。

（1）评审由饮料研发组组长主持。参加评审的部门一般包括饮料研发组、品管部、生产车间、采购部等部门。

（2）评审的内容主要包括饮料的感官特性、饮料的营养特性、饮料的安全卫生、饮料原辅材料的选择、饮料的包装、运输与贮存、饮料的预期用途、饮料的生产成本、饮料批量生产的可行性、新饮料所带来的环境影响以及与相关的法律法规和标准的符合性。

（3）将评审的结果及评审后应采取的必要措施记录在“产品研发评审表”上。“产品研发评审表”经饮料研发组组长批准后下发相关部门。饮料研发组应对评审中要求采取的措施的执行情况进行跟踪。

4.4 饮料研发配套工作的开展

4.4.1 完成与饮料有关的全部技术文件。（1）饮料研发组完成与饮料有关的全部技术文件。要完成的技术文件可包括：

① 产品描述（含终产品的预期用途）。

② 原料、辅料、与产品接触的材料的特性描述。③ 产品配方，产品标准/技术条件（含包装标准）。

④ 采购物资技术要求（原料、辅料、与产品接触的材料的采购标准）。⑤ 包装盒、使用说明书等包装图样及包装文件（含饮料标签），等等。（2）对饮料的安全食用所必需的产品特性、注意事项，应标识在相关的技术文件中，或在技术文件中做特别的说明。

（3）全套技术文件由饮料研发组组长审核、饮料研发组组长批准后下发。4.5小批量试制

4.5.1 工艺方案的编写。

小批量试制前，饮料研发组应对生产过程进行策划，编写小批量试产的“工艺方案”。

“工艺方案”的内容可包括：（1）对工艺工作量的大体估计。

（2）设备的购置或设计、改装意见。（3）专用工艺装备设计、制造意见。

（4）生产工艺流程的建议，关键工序点（含工序质量控制点CP、饮料安全关键控制点CCP）设置的建议。

（5）提出应编写的全部工艺文件及要求。（6）对工艺、工装的验证要求。

（7）对检测手段、检测方法的建议。（8）生产节拍安排、投产方式的建议。（9）环保建议。

（10）车间平面布置的调整建议，等等。4.5.2工艺方案的评审。

在工艺方案实施前，饮料研发组组织有关部门对其进行评审，以确认工艺方案的正确、合理与完整性。参加评审的部门一般包括品管部、生产部、设备部等部门。

评审的内容可包括：

（1）工艺方案和工艺流程的合理性和经济性，满足产品质量、安全要求的符合性。

（2）工艺设计的可行性，包括特殊和专门的工艺要求。

（3）可检验性和可试验性，检验方法的合理性，检验手段的适应性，包括特殊检验用设备和仪器。

（4）工装设计的适用性和设备选型的合理性。（5）环保的可行性与合理性。

（6）关键工序点（含工序质量控制点、饮料安全关键控制点）设置及工序质量因素分析的正确性。

饮料研发组整理出“工艺方案评审报告”。“工艺方案评审报告”应记录工艺方案评审的结果及评审后应采取的必要措施。

工艺方案评审之后，着手进行工艺装备的设计，危害分析及HACCP计划的建立，工艺规程、工艺文件的编写等。

4.5.3编制车间平面布置图。

必要时，饮料研发组应编制车间平面布置图，车间平面配置图上要注明人流、物流走向，设备分布，卫生管理区域，检测点，CCP点，贮存区等。

4.5.4 绘制产品工艺流程图，并编制工艺描述。

（1）饮料开发部工程师绘制产品流程图。流程图的内容包括： ① 操作中所有步骤的顺序和相互关系； ② 源于外部的过程和分包工作； ③ 原料、辅料和中间产品投入点； ④ 返工点和循环点；

⑤ 终产品、中间产品和副产品放行点及废弃物的排放点。（2）饮料研发组编制工艺描述，对过程流程图中的每一步骤的控制措施进行描述。工艺描述的内容包括过程参数及其实施的严格度、工艺控制方法及要求、工作程序，还包括可能影响控制措施的选择及其严格程度的外部要求（如来自顾客或主管部门的要求）。

4.5.5工装、设备的配置。

按《工艺装备管理规定》的要求做好工装的设计、制造与验收，确保在小批试制前到位；按《设施、设备管理程序》的要求做好生产设备的配置工作。

4.5.6监测装置的配备。

品管部按《监视、测量设备和方法控制程序》的要求做好监测装置的配置，确保在小批试制前到位。

4.5.7 进行危害分析并建立OPRP操作性前提方案、HACCP计划。

（1）在工厂布局、工艺流程完成，设备、工装到位，工艺文件（作业指导书）最终定稿之前，生产副总经理牵头成立饮料安全小组，进行危害分析并建立OPRP操作性前提方案、HACCP计划。详见《危害分析与HACCP计划建立控制程序》。

（2）OPRP操作性前提方案、HACCP计划建立完成后，饮料安全小组要对其有效性进行确认，详见《确认、验证、验证结果的评价与分析控制程序》。

4.5.8 编制过程指导书（工艺规程）。4.5.8.1饮料研发组根据工艺流程图、工艺描述、OPRP操作性前提方案、HACCP计划及相关标准编写指导工人操作和用于生产、工艺、环境管理的工艺文件，包括工艺卡/作业指导书、原辅料定额等。

工艺文件中应对关键工序、特殊工序、工序质量控制点CP、饮料安全关键控制点CCP作特别的注明。

（1）关键工序的设置原则

◆对最终产品的特性（感官、营养特性等）有直接影响的工序。◆产品特性形成的工序。

◆工艺难度大，质量较易波动或问题发生较多的工序。（2）特殊工序的设置原则

◆工序结果不能通过其后的检验和试验加以验证。

◆工序结果的缺陷仅在后续的过程乃至在产品食用后才显露出来。◆工序结果需实施昂贵的测试才能获得证实。

4.5.8.2饮料研发组编制供包装工人使用的包装作业指导书。4.5.8.3 品管部编制检验作业指导书。4.5.9小批量试生产。

4.5.9.1做好小批生产的准备工作。

（1）饮料研发组用“小批试制准备情况检查表”检查设备、工装、监测装置、工艺规程的准备情况，确保设备、工装、监测装置、工艺规程、HACCP计划、OPRP操作性前提方案在试生产前准备到位。

（2）生产部计划科作好车间生产计划并统筹试制物料的采购。4.5.9.2饮料研发组填写“小批试制申请报告”，经品管部、生产部会签评审后，报饮料研发组组长审核，总经理批准后实施。

4.5.9.3 在试制准备工作完成后，开始进行试生产。

（1）试制前三天，由饮料研发组组长主持召开产前会，落实试制准备情况并明确各部门在试制中的作用。同时由研发工程师讲解试制过程中的检验和生产要点。

（2）饮料研发组指导车间根据工艺文件、HACCP计划、OPRP操作性前提方案进行试制工作。试制中，品管部等部门应做好配合。试制中发现的问题应及时以“信息联络单”的形式向饮料研发组反映。

4.5.10研发验证——试制产品的检验。

品管部从试产的产品中抽样进行感官、理化、微生物检测，出具相应的“产品检验报告”。

4.5.11小批试制总结

试制结束后，饮料研发组应对试制工作进行总结，编写“小批试制总结报告”。

4.5.12特约顾客的品赏。

营销部向特约顾客发放试产的饮料供其品尝。营销部根据顾客品尝的情况，填写“顾客食用报告”交饮料研发组。

4.5.13产品鉴定（研发确认）。

饮料研发组按照试制、检验验证、顾客食用品尝中所提出的改进意见对配方、技术文件、工艺文件、HACCP计划等进行修改补充后，适时召开产品鉴定会，审查通过产品标准。

4.5.13.1 产品鉴定会由饮料研发组组织，饮料研发组组长主持，营销部、品管部、生产部等部门参加。

4.5.13.2 产品鉴定会召开时，饮料研发组应准备鉴定资料，包括饮料开发任务书、饮料开发输出文件、OPRP操作性前提方案、HACCP计划、评审验证记录、小批试制总结报告、顾客食用报告等。

4.5.13.3 与会代表对这些鉴定材料进行审查，提出对产品配方、技术文件、产品检测、生产条件、环境保护及顾客食用等方面的意见，在此基础得出鉴定结论，通过产品标准。

鉴定结论包括：

（1）产品达到“饮料开发任务书”及顾客要求的评价。

（2）产品技术文件、工艺文件、OPRP操作性前提方案、HACCP计划是否齐全、统一、正确，能否正确指导生产的评价。

（3）饮料质量、饮料安全、工艺、技术水平、生产能力、环境保护的先进性，顾客食用的感官特性、安全性、营养性以及采用国内外先进技术标准等方面的评价。

（4）是否具备批量生产的条件。4.5.13.4 饮料研发组整理出“产品鉴定报告”，“产品鉴定报告”应记录鉴定的结论及应采取的改进措施。“产品鉴定报告” 经饮料研发组组长审核、总经理批准后下发相关部门。

4.5.14 完善批量生产的准备工作。

4.5.14.1饮料研发组对产品鉴定中提出的改进意见进行落实。4.5.14.2相关部门完善与其有关的批量生产的其他准备工作。4.6 研发改进

4.6.1研发改进的申请（1）凡与饮料相关的人员均可对饮料中存在的缺陷及不足提出饮料改进申请。（2）因工艺调整、检测设备测试能力所限，采购或外协加工困难和顾客反馈的有关饮料缺陷，由相关部门提出饮料改进申请。

（3）饮料改进申请采用“信息联络单”的形式提出，由申请部门填写后，交饮料研发组。饮料研发组应将是否接受改进的信息反馈给申请部门。

4.6.2饮料改进的实施

（1）饮料研发组对“信息联络单” 提出的改进申请进行分析，确定是否进行改进。

（2）重大的饮料改进均应按本程序的有关规定进行适当的评审、验证和确认。

（3）一般的饮料改进，由饮料研发组负责跟进直至达到预期的改进效果。（4）技术文件、工艺文件、OPRP操作性前提方案、HACCP计划改进时，应填写“文件更改通知单”，经饮料研发组组长批准后连同相应的文件分发给有关部门或人员。

4.7 饮料研发技术文件的管理

依据《文件控制程序》对饮料研发中的技术文件进行管理和控制。

5.支持性文件

5.1 《工艺装备管理规定》 5.2 《设施、设备管理程序》

5.3 《监视、测量设备和方法控制程序》

5.4 《危害分析与HACCP计划建立控制程序》

5.5 《确认、验证、验证结果的评价与分析控制程序》 5.6 《文件控制程序》 记录

6.1饮料开发建议书 6.2饮料开发计划书

6.3饮料开发费用预算表 6.4信息联络单

6.5饮料开发任务书 6.6样品试制记录表 6.7产品研发评审表 6.8工艺方案 6.9工艺方案评审报告

6.10小批试制准备情况检查表 6.11小批试制申请报告 6.12产品检验报告

6.13小批试制总结报告 6.14顾客食用报告 6.15产品鉴定报告 6.16文件更改通知单

第三篇：药物研发流程

通常，从药物研发到普通药品上中须经过以下几个过程

①研发筛选（R＆D Screening），包括市场凋查（Market Survey）与专利调查（Patent Survey）；②临床前研究（Preclincal Studies）；

③临床阶段（Clinical Phases）；

④新药批准上市（New Drug Approval）；

整个研究是一个循环往复的过程，其中缺一不可。在药物研究过程中，更多的是依赖精心加上处理过的专业信息。我们应该选择针对性强、质量高、覆盖面大、有权威性的检索工具。另外，信息源的可靠性、获取数据的方便性、检索的效率都是是我们要考虑的首要因素。DIALOG系统具有600多个数据库，其中和制药相关的数据达200个，这些数据库在为制药企业提供各个环节数据和信息的同时，还利用其功能庞大的指令检索系统为企业提供了优秀的信息和情报的解决方案。研发筛选阶段

药物的研究开发途径主要包括：合理药物设计，组合化学技术，从天然产物中寻找新药，仿制安全、有效、市场需要的国外新药，开发新制剂、新剂型、新药用辅料等。在此阶段可选择下列数据库。

1.1 Current Contents（科研近期报道）

该数据库主要提供临床医学，生命科学，工程学，技术与应用科学，农业，生物学与环境科学，物理学，化学与地球科学，社会与行为科学，以及艺术与人类学等方面信息。

1.2 Chemical Abstracts（美国化学文摘）

该数据库主要收载生物化学、有机化学、大分子化学、应用化学、化学工程、物理化学、分析化学、理论化学、环境化学、农业化学、化合物和化学物质性质与反应，技术与操作规程，材料，仪器设备，理论与应用等信息。

1.3 Beilstein（贝尔斯坦文摘）

该数据库提供了900多万个有机化合物的结构资料和一千多万个化学反应资料以及两千万有机物性质和相关文献，包含可供检索的化学结构和化学反应、相关的化学和物理性质，以及详细的药理学和生态学数据在内的最全面的信息资源。收录的资料有分子的结构，物理化学性质，制备方法，生物活性，化学反应和参考文献来源，最早的文献可回溯到1771年。其中收录的性质数值资料达3000万条，化学反应超过500万种。

1.4 Biosis Previews（美国生物文摘数据库）

该数据库收录了1969年以来的《生物学文摘》（BA）和《生物学文摘综述、技术报告、会议文献》（BA/RRM）以及BA/RRM 1980年创刊时的前身检索刊物《生物研究索引》（Biobesearch Index）。内容涉及细胞学、动物学、基因学、植物学、微生物学以及相关学科：包括生物化学、生物工程、农业、生态学、食品科学与研究、医学、生物技术、环境研究及药理学等。

1.5 Incidence &-Prevalence（发病率与患病率）

该数据库提供流行病学、发病率、患病率、死亡率、疾病趋势、花费、风险因素、以及疾病分类等信息。

在药物筛选阶段，还应该进行市场调查（Market Survey）和专利调查（Patent Survey）。

在市场调查阶段，使用Dialog Newsroom和Dialog Profoud数据库可以获得全球超过10,000种新闻期刊和来自130多个市场研究机构超过20万份市场调研报告。我们也可选择以下数据库资源：①Pharmaco-economics（药物经济学）；②SCRIP（World PharmaceuticalNews世界制药新闻）等期刊。③FREEDONIA（Freedonia Market Research）（美）国际市场研究；④DATAMONITOR（Dtamonitor Market Research）（英）国际市场研究等。

专利调查：在药物筛选阶段，应全面系统地做好药物专利的调研分析工作。由于药品的特殊性，药物专利的查询需要从化合物专利、制剂专利、应用专利、甚至是近似专利等多方面进行。同时还需要对相关专利做好侵权分析、技术分析、权利要求分析、法律状态分析等深入的调研工作。因此，在此阶段可选择下列数据库：

① IMS Patent Focus（IMS药物专利数据库）

该数据库提供了超过1,000种商业药品及其相关产品的专利申请状况，市场动态和III期临床试验之后的信息，包括药品的属名、药厂编号、CAS注册号、化学名称、同义词、治疗说明、专利文摘、发展历史、世界范围发展的最新阶段、商业潜力和公司活动。

②Derwent World Patents Index（WPI，德温特世界专利索引）

该数据库是Thomson Derwent公司的产品。每条数据记录除了都包含相关的同族专利信息，还包括由各个行业的技术专家进行重新编写后的专利信息，如新颖性、技术关键、优点等。该数据库的重点在于专利的重新改写和修复，把模糊的技术信息明确化，把冗长复杂的专利信息简单化，方便信息人员了解和掌握专利的核心信息。

③ INPADOC（同族专利/法律状态数据库）

INPADOC同族专利/法律状态数据库是欧洲专利局的产品。数据来自66个国家和组织的专利信息。记录内容除了相关专利完整的同族专利，还包含27个国家的详细法律状态记录。该数据库重点在专利的全球同族专利及专利的详细法律状态。

④ 全球主要国家专利信息

美国专利（全文）

欧洲专利（全文）

德国专利（全文）

PCT专利（全文）

日本专利（摘要）

中国专利（摘要）临床前研究阶段

新药的临床前研究包括：药物的制备工艺、理化性质、纯度、检验方法、处方筛选、剂型、稳定性、质量标准、药理、毒理、动物药代动力学等研究。在此阶段可选择下列数据库：

2.1 Derwent Drug File（德温特药物文档）

该数据库收录1983年至今几乎所有关于药物科学的文献，年收录量约10万条，数据来源于1200种科学出版物，包括世界范围内的期刊和会议录。其中大约11％的资料来源于非英语语种文献。内容涉及药品开发、生产制备、药物评价等方面；包括分析化学、生物化学、内分泌、免疫学、医学、微生物学、制剂学、药理学、生理学、毒理学等。

2.2 Embase（荷兰医学文摘）

该数据库每年收录50万条记录，其中80%附有文摘。和其它医学文摘不同的是，该数据库收录了更多药学方面的信息，50％以上的内容来源于欧洲地区的期刊。EMBASE对每一条记录都进行了分类，医学研究专家还可以使用EMTREE中的关键词查找所需文献，EMTREE是一种比较先进的分类表和可控词汇表，由46,000个词语和20万个同义词组成，涉及药学、毒物、临床、实验医学、生物、公卫、环境、精神、法医、生医等诸多学科。

2.3 Medline（美国医学文摘）

该数据库收录了1966年以来美国和70多个国家出版的近4000种国际性杂志的文献，内容涉及基础医学、临床医学、环境医学、营养卫生、职业病学、卫生管理、医学保健等领域。目前，有70％以上的记录带有原著者自撰的摘要，每周更新一次，年更新量达36万多条记录。临床研究阶段

新药的临床研究包括临床试验和生物等效性试验。临床试验分为Ⅰ、Ⅱ、Ⅲ、Ⅳ期。Ⅰ期临床试验：为初步的临床药理学及人体安全性评价试验。观察人体对于新药的耐受程度和药物代谢功力学，为制定给药方案提供依据。Ⅱ期临床试验：为随机盲法对照临床试验。对新药有效性及安全性作出初步评价，推荐临床给药剂量。Ⅲ期临床试验：为扩大的多中心临床试验。遵循随机对照原则，进一步评价药物的有效性及安全性。Ⅳ期临床试验：为新药上市后监测。在广泛使用条件下考察疗效和不良反应。在此阶段可选择下列数据库：

3.1 ADIS R＆D Insight（ADIS药物研究与开发数据库）

该数据库偏重药物的商业信息，信息来源于药物公司调研、高层访谈和官方发布的资料，还包括一些医学期刊、国际会议，科学论文和专利文献等。数据库内容包括每种药品的属名、药厂编号、CAS注册号、化学名称、同义词、治疗说明、专利文摘、发展历史、世界范围发展的最新阶段、商业潜力、公司活动、科研进展和专利信息。

3.2 Pharmaproject（PJB，药物/生物技术项目数据库）

该数据库的信息来源包括非公开渠道和公开渠道，非公开渠道来自与药物公司相关人员的访谈，国际会议和各种调研活动；公开渠道包括期刊、学术资料和会议论文等文献。数据库内容包括正在研制的药品，和已经广泛投放市场的药品，以及由于毒性或商业而终止发展的药品数据，数据记录包含行业名称、化学名称和同义词、治疗说明、药学机理，发行公司与登记号、发展状况等。

3.3 IMS R＆D Focus（IMS药物研究与开发数据库）

该数据库偏重药物的商业信息，信息来源于药物公司调研、高层访谈和官方发布的资料，还包括一些医学期刊、国际会议，科学论文和专利文献等。数据库内容包括每种药品的属名、药厂编号、CAS注册号、化学名称、同义词、治疗说明、专利文摘、发展历史、世界范围发展的最新阶段、商业潜力、公司活动、科研进展和专利信息。

3.4 Medline（美国医学文摘数据库）

3.5 Embase（荷兰医学文摘数据库）新药上市批准（申报与审批）

新药批准上市之前，为了保障上市药品的安全，需要对药物进行不良反应进行监测、评价和预防，其最终目的是提高临床合理、安全用药水平，保障公众用药安全。通过以下数据库可以实现这些方面信息的查询和监控。

4.1 Toxfile（毒理学数据库）

该数据库收录了1964年至今有关化学品、药物和试剂对生命系统的副作用信息，部分数据来源于《美国医学索引》（Medline）中派生的《毒物学目录》（TOXBIB）于文档。内容包括毒物学、药理学、生化学、药品化学反应、药物不良反应、致癌作用、突变性、畸形性、辐射、环境污染、食物污染等。

4.2 Embase Alert（荷兰医学文摘警示）

该数据库提供最新的生物医学和有关药物研发方面的文献，包括药理毒理、不良反应、药物相互作用等诸多方面的内容。文摘型数据库，信息每周更新一次。

4.3 International Pharmaceutical Abstracts（IPA，国际药学文摘）

该数据库收录了1970年以来全世界750多种药学核心期刊文献，总记录接近40万条，每半个月更新一次。内容包括药物副作用、生物药理学、药物分析、药物评估、药物相互作用、药物代谢和体内分布、药物稳定性、历史、信息进展和文献；公共药物实验、调查研究的药物、立法、法律和法规；方法学和药物测试、药物化学、制药学、药物经济学、生物学、制药试验、药理学、社会学、经济学和伦理学、毒理学等诸多方面。

4.4 ADIS R＆D Insight（ADIS药物研究与开发数据库）

4.5 Derwent Drug File（德温特药物文档）

4.6 Medline（美国医学文摘数据库）

4.7 Embase（荷兰医学文摘数据库）

第四篇：研发工程部管理制度及流程

研发工程部管理制度及流程

1．目的和作用：

新产品开发是企业在激烈的技术竞争中赖以生存和发展的命脉,它对企业产品发展方向、产品优势、开拓新市场、提高经济效益等方面起着决定性作用。为了使新产品开发能够严格遵循科学管理程序进行，取得较好的效果，特制定本制度；

2．范围：

公司内工程部日常工作内容等各项流程的管理； 所包含的过程具体见如下章节：

2.1负责新产品的设计与开发，现有产品的改良； 2.2新产品工艺的贯彻与落实； 2.3产品材料的改良

2.4工艺文件的编制与核准

2.5生产中技术问题的解决；

2.6客户样品的跟踪，采购样品的确认

2.7 BOM表（产品零件结构表）的编制与管理

2.8 新材料供方的联系，新材料应用技术问题的改善 2.9新产品质量的跟踪

2.10协助品质部建立品质标准与计量标准化工作 2.11指导生产部做好机器、设备的保养与维护 2.12供方的评审

2.13特采作业的核准

2.14负责公司工程资料的制作，发放及存档 2.15负责样品的打样

2.16负责样板、夹具的图纸制作

2.17在整个开发阶段系统地衡量客户的满意度

3．权责： 权力

3.1有权参与公司生产政策的制定； 3.2有权参与公司产品开发战略的制定

3.3有权参与公司、季度、月度生产计划的制定，并提出意见和建议 3.4对违反操作工艺的行为和过失有实施处罚的权力 3.5部门内部员工考核的权利

3.6部门内部员工聘任、解雇的建议权 3.7其他上级授予的权力 责任

3.8对产品和技术开发计划完成负主要责任 3.9对技术保密负领导责任

3.10如因工作失职，给公司造成损失，应负相应的经济和行政责任。

4.工作流程图

4.1.研发部工作流程图

4.2.工程部工作流程图

5.技术图纸的管理制度流程

5.1技术文件的形成与发放

5.1.1任何一份技术文件的形成都是公司员工辛勤劳动的成果和员工智慧的结晶，但其中还饱含了公司巨大的前期投入、过程控制和后期经营等因素，显而易见是公司投入了巨大的财力、物力，为每位员工提供了展示自己能力的平台，员工与公司在这个平台上共同进步和发展的过程中形成了种种技术文件。5.1.2技术文件、技术标准及图纸资料的形成应严格执行设计（编制）、校对、审核三级把关制度；明确各级的责、权、利。

5.1.3技术文件标题栏中的编号、名称、日期，设计、校对、审核、批准等栏中应签署齐全，签署不全的技术文件不得投放到相关部门，更不得使用。

5.1.4图纸投入使用，即投放到各使用单位（部门）之前，必须加盖“文件副本”、“受控

文件”章，由技质部门发放到各使用单位并进行登记，或由使用单位提出申请，技质部负责图纸的发放。

5.1.5纸质技术文件或电子档技术文件等由技质部收存并负责保管。员工借阅技术文件应凭部门经理批准的借阅申请单向技质部借阅，用完后及时归还，并保证资料的完整性。

5.1.6技术文件的修改必须按级、按各职能部门的业务分管范围执行；技术文件修改前，负责修改部门要提出修改理由及具体内容，交有关领导审批。

5.1.7修改后的技术文件必须重新履行会审、会签及批准手续，填发更改通知书。

5.2技术文件的管理与存档

5.2.1技术文件是公司进行生产和各项管理工作共同的技术依据，必须加强管理，各部门应

指定一名专职或者兼职资料员负责各种技术文件的登记、保管、复制、收发、注销、归档和保密工作，保证技术文件的完整，准确清晰、统一等。若暂时未指定资料员，则由部门经理暂行代理。部门经理和资料员负责本部门技术文件的保密、发放与归档。

5.2.2技术文件、图纸由技质部备份、存档，技质部定期对技术资料进行整理。5.3技术文件的保密

5.3.1技术文件任何部门、个人不得擅自打印、复制，不得以电子文档等形式在网上传递或

者用移动硬盘、U盘、软盘等拷贝出。因工作需要必须打印或复制时，经办人提出书面申请单，部门主管签字批准后方可通过技质部资料员打印、复印、拷贝。

5.3.2为了保证技术资料的保密性，除按正常程序（员工填写申请单，部门主管批准）办理 外，任何人不得私自向外人转让和借出技术资料，一经发现要报公司给予严肃处理。5.3.3若不负责任的遗失技术文件或者因为种种原因泄漏公司的技术文件，公司将根据有关 保密规定给予罚金处罚和公司内部记过处罚,情节严重者公司将保留追究法律责任的权利。

5.4技术文件的销毁

5.4.1 由于新技术的日新月异，越积越多的技术文件会占据不必要的资源，故有的技术文件需要销毁和清除。

5.4.2 需要销毁的技术文件由资料员提出，部门经理会同有关技术人员一起仔细校对核实，然后将销毁理由与销毁文件清单上报总经理室，由总经理签署“同意”后，方可销毁。

5.4.3销毁的纸质文件必须经过碎纸机或者烧掉，光盘等文件必须锤击粉碎。

6.业务样品单制作流程

6.1业务下《客户订单－样品单》

6.2工程指定人员填写《客户订单－样品单》的技术参数并评估交期 6.3业务发放《客户订单－样品单》给各部门

6.4工程跟据《客户订单－样品单》填写申购单/领料单或自己申购物料 6.5工程跟踪到料情况――制作样品――测试/老化样品 6.6工程包装――入成品仓――通知相关业务 6.7业务按单发货－工程/仓库须签字 6.8工程做好样品BOM表及样品跟踪记录

7.业务量产单制作流程

7.1业务下《客户订单－量产单》

7.2研发指定人员填写《客户订单－量产单》的技术参数并评估交期 7.3业务发放《客户订单－量产单》给各部门

7.4研发跟据《客户订单－量产单》制作BOM表，及相关技术资料（图纸），标签及说明书 7.5研发将相关文件发放相关部门并存档 7.6研发确认相关物料

7.7生产时工程须现场指导及跟进

研发工程部用相关文件表单列表

1设计计划书 2设计任务书

3设计任务输入清单 4设计确认报告 5设计任务输出清单 6设计验证报告 7样板检测记录 8设计评审报告 9设计变更改通知单 10图纸资料发放记录表 11图纸资料申请领用表 12图纸资料销毁申请表 13.物料申请单 14领料单 15内部联络单 16.样品跟踪记录表 17.入库单

第五篇：产品研发流程管理制度

产品研发管理制度 第一章总则

第一条产品研发过程的管理，指产品研发项目确定后，进行产品研发，形成可交付使用的软件产品的过程。在产品的研发过程中，做好研发流程的管理和控制，是确保产品研发质量和研发进度的关键。

第二条本流程制定的目的是为了对产品研发进行有效的组织实施，使产品研发处于受控状态，保证软件开发的最后成功，向用户提供高质量的软件产品。产品的需求分析管理 需求的采集

采集的渠道分为市场反响、竞争对手分析、客户反馈、运营数据分析、公司内部的建议等方面。

第四条需求的分析及编制文档

采集到的需求经过深入了解和系统分析，通过跟用户的讨论验证，并形成产品需求文档，让开发、设计人员理解产品的概念，功能、特点及产品各个部分的逻辑。产品需求文档包括业务需求、用户需求、功能需求和非功能性的需求。

1、业务需求：反映客户对系统、产品高层次的目标要求，在项目定义与范围文档中予以说明。

2、用户需求：描述用户的目标，或用户要求系统必须要完成的任务，这在使用实例或方案脚本中予以说明。

3、功能需求：规定开发人员必须在产品中实现的软件功能，使用户利用这些功能来完成任务，从而满足了业务需求。

4、非功能性需求：描述软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性（联机帮助、数据管理、用户管理、软件发布管理、在线升级等）、性能、可靠性、可维护性、可扩充性、适应性等。工作责任人

需求分析工程师

工作职责概述

需求采集、用户调查、业务分析、系统分析、变更管理、用户验证

工作关系

客户、市场、公司内部员工

工作成果

产品需求文档

产品的可行性分析报告、原型及评审管理 可行性分析报告

产品可行性分析报告的编制是为了明确产品项发立项之前的市场、技术、财务、生产等方面的可行性，论述为了实现产品研发目标而可能选择的各种方案、投资及效益分析、潜在的风险因素，论证所选定的方案的可行性。可行性分析报告编制完成后，由公司技术战略委员会组织完成对产品可行性分析报告的可行性初审和复审，形成相关议决后报总经理审批。第六条产品需求规格说明书

确定客户需求、根据产品需求文档形成产品需求规格说明书。用于保证软件开发的质量、需求的完整与可追溯性，通过产品需求规格说明书，以保证用户与需求分析人员、开发人员、测试人员及其它相关利益人对需求达成共识，确保产品需求的实现。第七条产品原型

原型图是对流程图中“界面元素”的展现，将页面的模块、原素、人机交互的形式，利用线框描述的方法，将产品脱离皮肤状态下更加具像跟生动的进行表达。工作责任人

产品经理、产品助理

工作职责概述

用户和市场分析、产品规划、产品需求管理、产品设计、推动产品研发进程、产品发布管理、产品宣传推广

工作关系

产品中心经理、需求分析工程师、研发中心、客户

工作成果

产品可行性分析报告、产品需求规格说明书、产品原型设计

产品的立项及评审管理 产品立项报告书

产品立项报告书含以下内容：

论证该类产品的技术发展方向和动向；

论证研发该产品具备的技术优势和市场动态；

论证发展该产品的资源条件可行性（含物资、设备、能源及资源等）； 初步论证该产品的技术经济效益。第八条立项评审及批复

公司技术战略委员会就产品立项报告书进行评审讨论，全面论证新产品的技术性、经济性及可生产性和实施性等方面，形成相关决议后报总经理批复。工作责任人

项目经理

工作职责概述

编写立项报告，并组织技术战略委员会进行评审

工作关系

工作成果

产品立项申请报告书、产品立项申请批复

产品的研发管理（概要设计、详细设计、开发）第九条团队建设

产品立项报告书经过审批后，根据总体产品研发计划、研发人员配备情况和产品需求规格说明书，由总经理确定相关的项目负责人与研发成员。第十条概要设计

项目组成员在产品研发进度时限内确定产品研发计划，根据产品需求规格说明书和产品原型对软件系统的设计进行考虑，出具DEMO设计、架构设计、数据库设计、模块设计、功能设计、部署设计等文档。第十一条详细设计

根据功能设计，定义画面具体元素，动作行为，跳转迁移流程，以及内部实现逻辑，数据流向等具体行为。第十二条产品研发

研发人员者根据概要设计、详细设计对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。第十三条在研发过程中，项目负责人应将产品的研发进度上报产品质量管理部，由质量管理部对产品的研发进度和质量进行监督。第十四条为增强公司的核心竞争力，新产品的研发时间一般不得超过三个月，特殊情况需要延长研发时间的，必须经技术战略委员会和总经理的审批同意。工作责任人

项目经理、架构师、研发人员、设计人员、运维人员

工作职责概述

项目模块功能的开发及单元自测

工作关系

产品中心、设计美工、测试人员

工作成果

DEMO设计、架构设计、数据库设计、模块设计、功能设计、部署设计等技术性文档，以及产品实现代码。

产品的测试管理

第十五条在软件设计完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。第十六条测试部根据产品需求规格说明书、产品研发计划制定产品测试计划，建立测试环境，组织测试环境评审，保证测试内容全面，测试结果客观有效。

第十七条执行确认测试流程，对测试结果进行记录，形成测试报告。

第十八条跟踪测试过程中出现的BUG，和研发人员协商，跟踪确认解决。第十九条产品测试报告和用户使用手册的编写，并报产品经理和研发经理。第二十条产品版本的发布 工作责任人

测试人员

工作职责概述

搭建测试环境、测试用例设计、测试执行、缺陷分析与管理、测试报告、用户使用手册的编写

工作关系

产品经理、研发人员

工作成果

测试报告、用户使用手册

产品的上线运营管理

第二十一条经过测试证明研发的产品达到要求后，研发人员和测试人员应提交下列文档给运营：“产品代码或安装程序”、《测试报告》、《用户手册》、《故障指导手册》、《系统实施手册》、《市场推广手册》。

第二十二条上线运营管理是产品生命周期的最后部分，也是时间最长的。主要包括下列工作：产品部署、硬件安装、用户培训、运营维护、问题反馈与建议。

第二十三条上线运营管理主要由系统运维工程师和实施维护工程师来完成。系统运维工程师侧重于各软件系统和平台的运营；实施维护工程师侧重于对自助柜等外围硬件设备的运营。第二十四条运营不仅是测试与市场推广的桥梁，给市场推广做支撑；而且，也是测试与产品需求的桥梁，根据运营过程中得到的问题和建议，反馈给产品需求，形成闭环。第二十五条运营是个长期过程，需要流程化。输出文档主要有：《安装检查表》、《用户培训文档》、《用户培训验收表》、《运营维护记录表》、《问题反馈与建议表》。工作责任人

系统运维工程师、实施维护工程师

工作职责概述

产品部署、自助柜安装、用户培训、运营维护、问题反馈与建议等

工作关系

产品中心、研发中心、客户

工作成果

《安装检查表》、《用户培训文档》、《用户培训验收表》、《运营维护记录表》、《问题反馈与建议表》

研发资料的管理

第二十二条产品的研发资料是公司的重要技术机密，一旦泄露将给公司带来巨大的损失，研发过程中的相关资料由研发中心负责妥善保管。

第二十三条研发资料管理人员根据技术文件目录验证研发资料是否齐全，不齐全时可拒收并上报研发中心经理，由中心经理负责处理。

第二十四条公司的任何人员不允许将任何研发资料以任何形式带离公司，否则，造成的后果由当事人承担。工作责任人

工作职责概述

工作关系

工作成果

研发费用管理

第二十五条每个项目的研发费用包括调研费、差旅费、对外技术合作费、外委试验费、专利申请费、加班费和公司规定的完成项目奖励等。

第二十六条产品的研发经费按单个项目的预算支付，单独列帐，独立核算，由财务部负责监督。产品的研发经费不得挪作他用。第二十七条在研发项目完成后，公司规定的研发奖金将按规定金额支付给项目研发小组，具体发放金额和方式由公司技术战略委员会确定后，上报总经理批准。工作责任人

财务会计

工作职责概述

工作关系

工作成果

产品研发的知识产权管理

第二十八条产品研发过程涉及到以下几方面知识产权管理：

著作权申请：对于产品开发过程中的源代码、产品样本，应进行著作权登记，作为公司申请科技成果的依据，并受《著作权法》保护。专利申请：产品开发过程中的发明创造，符合专利申请条件的，应申请专利，以取得法律对新产品的保护。

商标申请：新产品投放市场，应根据情况决定是否对新产品的品牌进行商标注册； 与外单位协作开发过程，在签定的相关协议中应包括明确知识产权的权属条款，争取公司的知识产权受到合法保护，避免公司无形资产受到损失。

商业秘密保护：对于在产品开发过程中的发明创作，如不适合申请专利的，应作为公司的商业秘密进行保护，应注意法律对商业秘密保护的相关规定，努力作好保密工作。工作责任人

项目申报专员

工作职责概述

对公司研发项目的知识产权的管理

工作关系

产品中心、研发中心、相关政府机构

工作成果

软件著作权、软件产品登记、专利、商标的申报

第十一章附则

第二十九条本制度由人力行政部制定，其解释权与修改权归人力行政部所有。第三十条本制度自审批、颁布之日起执行。附件：

1、产品中心文档模版

2、研发中心文档模版