研发管理部的职责

研发管理部的职责（精选8篇）

篇1：研发管理部的职责

研发管理部的职责

——抬头看路，低头看车

公司近几年来，尤其是以降低成本、技术创新为核心的发展思路，审视其中，我们又是以改造大量的旧产品为主要的利润来源，通过不断的降低产品的成本，支持在市场上的占有率。同时，在我们的研发内部，产品开发的周期、成本、决策评审、测试试产等方面都没有得到实质性的改善，大家在忧心忡忡之下，也在不断探寻着解决之匙。

如何解决这些问题，加强研发队伍的实力、更加重视研发软、硬件资源，是当前的首要方案。但是，研发体系已然是很庞大了，而且还正在急速的膨胀中，我想我们确实可以至少是思考一下，我们是否可以“向管理要效率，向管理要质量”，作为在研发管理部这个不用直接对产品开发直接负责的部门，更多的时候，是要做好检查监督和协调的工作，因此更多的时候，是可以来思考一下的。当然，重视自身保持对研发技术的学习和项目开发的各个环节的掌握将会一直是一个重要的工作，可以说不懂产品和技术，抛离市场和成本，实难做好研发管理。

当前研发存在的重要问题：

 其实公司对研发无疑是越来越重视了，对产品降低成本、技术创新、平台建设、研发队伍的重要性也有了进一步的关注，但整体上系统的研发管理还在进一步的发展当中。换句话说，我们目前还是处在重技术、轻管理的思维模式。也可以说，公司对研发最重要的两个因素是：市场需求（以市场为导向）和技术人才（企业核心竞争力），这说明研发管理还没有达到成为企业研发保持持续竞争力的关键。

 在产品开发中缺乏用产品成本评估的工具，来衡量一个项目开发的成本是否支持开发继续进行下去。所有的产品，只要不是公司叫停的，在产品线都是一个现象：只要立项，就一定要开发出来，也许直到产品上市了，市场就真正的检验出产品的成色，产品线没有能力及时砍掉已经没有前途的产品研发项目，导致产品研发资金的巨大浪费

 我们采用项目组的方式来负责产品研发。但是，真正有责有权、运作高效的项目组少之又少。更多的情况是，项目经理更像一个行政管理人员、记录人员或协调人员，而不是项目领导者；项目组不是真正的跨部门团队，大多数 项目组仅仅是由研发部门人员组成的；功能部门经理所拥有的权利和责任比项目经理大得多，责任划分模糊；项目成员的对部门的忠诚度远远超过对项目组的忠诚度。因此，一旦出了问题，部门之间就相互抱怨及推诿责任。

 产品成本的评估机制，至少说从目前的情况来看，我们并没有对（不是说所有项目）一些重要的项目产品进行过真正的成本评估，这样会产品几个问题：管理者对成本的管理（以市场为导向）不重视，投入不计量或者模糊，形成人力资源分配不均。产品所有的投入和最终的产出以及上市后何时盈利是可以估计的，这样不至于开发过程中一味的完成实际上不盈利的产品，也就是以完成工作为目的，而隐晦产品的实际价值。

 项目检查、督促、强力推进项目的机制的缺乏，我们研发内部其实开发效率其实不是很高，大家都有一种惯性思维和自我救赎的解释逻辑。尤其是在中层管理人员的想法当中，尤为突出。比如说：“项目进度只能真么做，没法再解决了”，“就算物料提前到位了，也难免不出现不浪费”，“做的再快也就这样，而且我作为项目经理也管不了”。究其原因，也和缺乏强力的检查和监督有关，有时候人就是很有趣，领导越重视，越强压，底下的员工反而做的又快又好。（典型的就是唐僧团队，有目标、有计划、有压力，也有协作）

以上罗列的是当前研发内部发生的一部分问题，当然，要说问题，可能还有很多，但是说多了而没有实际采取方案和真正执行，也是徒劳。在这里就不多说。但是，在整理方案之前，我还是想对跨部门的项目团队出现的问题进行一下归纳。

大家都清楚都明白，组建强有力的跨功能部门的项目团队是保证研发项目的进度和项目成功的关键要素之一。但是，现实是，由于各部门的人员价值观和对于他人的工作的理解程度，在公司内部，从来就真正没有形成过这样一个团队（也就是说，研发和市场人员对于自己的分工很清楚，各自的本位主义很强；同时对于双方的工作也不太认可，都认为自己的工作重要，从而缺乏团队荣誉感）

在这里，我还是觉得当时的“地平线”团队至少在当下，是最值得我们认同和思考的团队，及时它依然存在各种“普遍、常见”的问题，及时有时候团队间的貌合神离。

总结一下，一般跨部门团队的失败的原因：

（1）部门经理和项目团队的权责划分不清，或者从来就没划分过，部门经理决定一切；

（2）团队成员的责任不明晰，容易扯皮，原因还是没有团队荣誉感；（3）团队负责人（项目经理）无法起到跨部门沟通的能力，掣肘太多；（4）团队开发的完成目标不明确，如果以市场为准则，团队不能在项目移交生产后就解散，真正意义上来讲，谁开发谁负责，而不是都归项目经理。（这个是当前的架构问题导致的），从另外一个方面来讲，就因为有个领导在上面，项目经理本身也不会以十分的责任心来完成一件产品；（5）团队成员无法全身心投入到项目中；

（6）项目经理仅仅起到协调人的作用，决策权还无法实现；

从每个产品线抽调1-2名人员，来进行跨部门沟通的桥梁

评审

检查

文档

研发各信息搜集、进度汇总

人事

变更

篇2：研发管理部的职责

2. 负责新产品研发计划的制定与实施。

3.负责安排和计划新产品的研发和设计工作，管理和调配整个公司的研发技术

4. 编制设计部各项规章制度、工作程序、工作要求及实施细则，上报总经理审批。

5.严格贯彻执行各项制度、工作流程及操作规范，并对执行情况进行监督检查。

6.根据企业的实际情况，负责组织修订、完善部门制度、工作流程等，并发布实施。

7.组织、监督工艺方案、工艺流程的设计工作，审核工艺设计方案。

8.组织、指导设计新产品图纸并进行交底工作。

9.负责设计的变更、评审及修改工作，及时满足生产的需要。

10. 人员和模拟绩效考核，订单评审，全面主导公司的产品研发方案和成本控制。

11.负责设计部各职位工作的分配、指导、监督与考核工作。

12.按工作程序做好与市场部、技术部、生产部等相关部门的横向沟通，及时解决部门之间的争议。

13.负责跟踪和掌握国外、国内同类技术发展趋势，组织研发部内部技术论证会。

14.组织企业内部与外部的技术协作和技术交流活动。

15.编制设计费用预算，控制各项设计费用支出。

16.接受领导布置的专项任务和临时性任务。

17. 保持与公司最高层沟通，密切关注决策层意愿和企业发展战略目标。

结构工程师岗位职责

1.协助技术研发经理制定本部门发展规划和年度工作规划。

2.组织编制结构设计文件、图纸。

3.编写设计和目录。

4.组织收集结构设计资料，拟订结构设计计划。

5.主持结构设计的交底工作。

6.承担设计方案中的结构设计工作。

7.与生产部门沟通，做设计回访指导。

8.向销售部门提供说明，编制培训教材。

9.负责模具试模的跟踪。

10. 对原有产品和新开发产品建立完整的工业设计技术文档。

11. 负责跟踪前期生产，指导监督全部生产过程，及时解决生产中遇到的问题;

12. 产品完全成熟后，移交整套工艺性文件，指导、帮助生产系统人员进行生产，向市场部提供有关加工能力及价格的信息。

13.完成领导临时交办的其他任务。

电子工程师岗位职责

1.协助技术研发经理制定本部门发展规划和年度工作规划。

2.主要负责LED灯具的驱动电源设计开发工作，根据项目需求独立进行驱动电源的设计分析，并按照研发流程完成驱动电路设计的输入、样机开发、试制试产、放产、量产等工作;

3.协助研发经理完成电路计算分析，电子电路维修与优化;

4.电子元器件的品质标准及检验标准的建立;

5.指导编制产品使用说明书、作业指导书、产品安装、维修手册等技术文件资料;

6.新产品开发项目的配合跟进;

7.指导生产部门技术操作协助解决生产过程中的产品机械技术问题;

技术员岗位职责

1.协助项目负责人/工程师完成调试任务。

2. 协助项目负责人购买新材料或器件，组织相关物料制作样品，对项目试制的样品进行测试、验证并作相关详细记录。

3. 协助项目负责人制作认证样品或客户样品。

4. 协助项目负责人编写技术指导性文件。

5. 协助项目负责人跟踪项目试产过程、批产过程。

6. 将测试与试产、量产过程中出现的一些技术问题反应给上级以及相关的人员，分析问题，提出对问题的改进方案。

7. 负责技术工艺改进的具体验证实验的进行。

8. 负责协助收集本行业新的技术、材料、工艺信息。

9. 负责对公司产品的设计水平和工艺水平提出不断改善建议。

10. 负责部门之间的平行沟通协调。

11. 负责工作现场“7S”工作及研发部设备的保养及维护执行工作。

12. 上级交办的其他事务。

研发助理岗位职责

1.协助工程师做好新品的拍照、产品宣传页的设计、制作。

2.参与新技术、新产品的引进及研发。

3.配合工程师做好采购询价等工作。

4.协助研发项目的管理、监督和监控。

5.负责文字、表格材料的编写、制作、和审核等日常行政事宜。

6.根据客户需求和营销需要，制作各类产品和技术资料

7.协助所负责部门的研发辅助工作事宜;

8.协助研发流程的文档签署以及流程状态的跟踪;

9.协助做适当的部门管理统计工作;

10.研发资料、文档的内部归档和外部发送;

11.研发所需数据、资料的调研与整理;

12.负责研发部门的会议安排，记录，跟踪等等;

13.协助研发负责人协调研发各部门之间的日常工作。

14.配合销售人员，对客户提供技术服务和技术支持

15.合同跟单、落实、追踪。

篇3：研发管理部的职责

一、预算管理

对于银行研发中心而言，项目预算主要包括项目规模评估、项目工作量评估、项目工期评估、项目质量评估等。本节内容在此前连载中已有所论述。

二、质量管理

关于项目质量管理，有许多内容，包括项目质量的度量、影响项目质量的因素、项目质量的过程管理和过程改进等。相关内容可参考此前论述。下面来补充说明银行研发中心需要关注的一些问题。

（一）投入与质量的关系

为了保证生产安全，首先要保证产品的质量。但在任何产品生产过程中，都不可能追求毫无瑕癖，因为这会带来极大的投入，本身就是一种浪费。一般投入与质量的关系如图1所示。

投入与质量不是线性关系。越接近终极目标，需要付出的投入就越成倍增加。

对于研发中心而言，投入主要是指人力资源和时间资源，质量的指标主要是缺陷率。我们可以通过加大测试的人力资源投入、加长测试周期、模拟各种系统的应用情况，使缺陷率降到最低。它们两者的关系如图2所示。

对于一个既定的研发中心，要完成一定规模的任务，资源投入和缺陷率是负相关的。投入越大，一般缺陷率会越低。但很明显，两者的变化有一个边际效应：当缺陷率低到某个程度，加大投入带来的边际效果会越来越低。所以，从研发资源最大化利用的角度出发，应该把投入控制在整体质量可以接受的范围内，而不是追求完美无缺。

（二）不同产品的效率与质量，及其平衡关系

针对一定规模的任务投入一定的资源，如果忽略其他因素不计，整个版本质量基本能控制在一定范围内。但如何合理安排资源并平衡一个版本内各个项目的质量，从而得到整个版本最理想的质量分布，是一个非常值得研究的问题。

理论上，如果把研发资源(时间资源和人力资源)按项目规模大小平均配置在各个项目上，忽略主观因素不计，每个项目的质量应该差不多，这样整个版本的质量也应该能控制在一个既定的水平上。

但在现实情况下，项目的质量表现与预期大相径庭。一些原来非常希望其质量有好表现的项目，往往问题不断;另外一些认为相对不重要的项目，质量表现却不错。而整个版本的质量表现像木桶原理一样，一些重要项目质量表现不好，就像木桶的短板，整个版本的质量表现也不会好。问题出在哪里呢?恰恰是在平均配置研发资源上。

软件质量与质量表现不是一个概念。如果两个规模差不多的软件各自随机散列地隐含了相同多数量的缺陷，我们可以认为这两个软件的质量是差不多的。研发资源的平均配置，可以使软件隐含的缺陷趋于一致。但是，软件不同的应用环境，其质量表现会非常不一样。以下各方面因素会影响投产后应用的质量表现。

1. 应用被使用的频率

假设有A, B两个应用，其规模和内部构造大致一样。根据各自不同的应用场景，均有1 000种内部逻辑路径的组合，并且其中2种应用场景对应的内部逻辑有缺陷。这2个应用投产后，假设各种应用场景平均分布，出现问题的概率为0.2%。也就是说，平均每运行1 000次这2个应用均会出现2次问题。

但是，A应用一天会被使用100万次，B应用每天只被使用100次。这样，A应用平均每天会出现2 000个生产问题，而B应用平均5天才会出现一个生产问题。这样一来，两者在质量表现上的缺陷率就有天壤之别。

当然，上述的分析只是一种机械性的分析。实际上，缺陷不会平均分布，应用场景也不会平均分布。

2. 生产类应用还是管理类应用

通常，生产类应用的缺陷会直接影响银行对外的经营服务，而管理类应用不会或者只间接影响银行对外的经营服务。所以，同样的缺陷率，生产类应用比管理类应用的影响更严重。

3. 应用是否涉及计算机信息的变更

计算机信息的处理动作，大概可以归纳为增、删、改、查四类。其中，前三类动作会引起计算机信息的变化，而最后一类动作不会改变其内容。

对于不同的应用，如果其处理涉及计算机信息的变更，特别是涉及计算机重要信息的变更，例如客户资料重要信息的变更，客户的资产、负债资料的变更，甚至是大额的资产负债信息的变更等，其缺陷引起的生产问题会非常严重。有些信息的破坏甚至是不可逆的。而如果应用对应的计算机处理仅仅是信息查询，不会破坏计算机的固有信息，其缺陷引起的生产问题严重性会相对轻一点。

4. 应用涉及的当事人

此前说过，银行计算机应用系统的当事人不但包括银行内部人员、银行客户，还有第三方机构和监管机构。

如果应用是内部应用，仅涉及银行内部相关人员，其缺陷产生的生产问题影响范围一般只在银行内部。如果应用是外部应用，涉及的当事人还包括银行客户，其缺陷的影响会涉及银行和银行客户双方。如果应用还涉及第三方机构或监管机构，其影响除了银行客户，还会涉及第三方。较大的生产问题还会产生不良社会问题，会给银行信誉带来很大损害。

可见，对于银行来说，由于其应用环境和处理的内容不一样，不同的应用应该有不同的质量要求。如果该应用(项目)交易量比较大，会引起计算机重要的资料变化，甚至是大额的资产负债资料的变化，而且是外部客户使用的，甚至还涉及第三方，那么，对其质量要求应该最高。反过来，如果该应用(项目)涉及的交易量很少，是内部员工使用的，不涉及客户、更不涉及第三方的资料变化，那么，对其质量要求相应最低。

这样才能有最好的投入产出。研发中心不单要关注产品的质量，更应该关注产品的质量表现。只有重要产品有较好的质量表现，应用系统才能取得最好的整体质量。这就是平常所说的，好钢要用在刀刃上。

（三）改进办法

在现实上，研发中心研发的应用种类繁多。一般来说，由于不同的应用采取的软硬件技术平台、工具、语言不同，生产效率也会有不同。加上运行环境不一样，去掉主观因素，也会有不同的质量表现。根据上述对不同应用场景的分析，可以把不同质量要求的应用分类。例如分成不同的4类，1类质量要求最高，4类质量要求最低。

通过对银行实际生产问题进一步分析，发现问题出现最多最严重的是1类应用，问题出现最少最轻的是4类应用。这就验证了前面所说的：质量期望值越高的应用，往往表现为质量不高;而质量没有被寄于厚望的应用，质量反而比较高。

其原因是明显的，恰恰与我们对不同类应用的定义相关。

例如4类应用，首先，它的交易量少，问题出现的几率本来就很低;其次，它是内部管理类应用，而内部员工对应用缺陷的承受力一般比银行外部客户大;最后，由于它不涉及客户相关资料的变更，也不可能犯这方面的错误，并且更不会犯下涉及第三方的错误。而1类应用由于交易量大，犯错误的机会多，且错误会涉及资金的差错和损失、客户和相关合作方，因此对社会影响较大。

根据历史数据的分析，忽略其他原因，如果对不同的应用投入(效率)一样，即每百功能点的研发规模投入相同的人力资源和时间，在平均缺陷率表现统计上，1类应用会比4类应用起码高出2-3倍。并且这只是考虑了缺陷的数量，还没有考虑缺陷的严重程度。

上述结果有2个值得注意的地方：一方面，前提是我们对不同类的应用投入一样;另一方面，结果并非我们期望的结果。

如何解决这个问题?我们可以通过人为地调节研发资源来解决。

从研发中心的资源配置来说，对于高质量要求的项目，应该配以比平均资源更多的资源，以保证其有更高的质量。当然，该项目的效率要求就低一点。反过来，对于低质量要求的项目，研发中心要求其有比平均效率更高的效率。也就是说，分配较少的资源给它。当然它的质量相对会低一点。

让我们重新回顾一下质量与投入的关系图。为了方便起见，我们把该图再展现一下，如图3所示。

从图3可见，在时间资源和人力资源均压缩50%的情况下，缺陷率大概增加一倍多。也就是说，假设在资源平均分配时，1类应用的缺陷率比4类应用的高一倍。如果以1类应用作为标杆，要让1类应用与4类应用缺陷相当，在项目资源分配上，4类应用应该比1类应用压缩资源50%;如果以4类应用作为标杆，要让1类应用与4类应用缺陷相当，在项目资源分配上，1类应用应该比4类应用分配多一倍以上的资源。通过这种资源调节方法，在实际运行中，可以达到两类应用在质量上表现一样。

但这还没有达到理想的目标。考虑到缺陷的不同严重程度，我们还希望1类应用在实际运行中的表现要好于4类应用。例如，缺陷率低于20%。

再看一下图3，如果资源分配相差20%，缺陷率大概也会相差20%。我们可以在原来的基础上进行最终的资源分配，让1类应用比原来平均资源多获得20%，让4类应用在原来平均资源分配基础上压缩50%。这样，两类应用资源分配的权重比为1.2:0.5，也就是2.4:1。这个结论出人意料。并且前提是当资源平均分配时，原来4类应用与1类应用相比，其缺陷率表现为1:2。如果原来差别更大，那么结论就会更惊人。

这种方法的可操作性究竟如何，实际效果会如何?让我们来算一下。为了简单起见，假设应用只有1类和4类，并且，出于安全考虑，希望要求整个应用系统质量高一点。所以在定义上，1类应用在数量上一般比4类应用多，假设比例为7:3。相对应的，其研发工作量比例也为7:3。

先看资源分配的情况(见表1所列)，资源分配前后方案的总资源基本一样。也就是说，把4类应用压缩出来的资源基本上都分配给了1类应用。

再看质量表现(见表2所列)，通过资源分配的优化，在整体版本质量基本不变的前提下，1类应用和4类应用的实际表现已经基本满足需求。

当然，实际情况要复杂得多，上面表述的仅是一种方法论。

三、风险管理

软件工程管理的一个重要理念，是强调过程风险管理。只有每一个过程达到目标，才能保证软件工程达到最终目标。为了保证项目的进度和质量，过程风险管理是非常重要。

风险管理的展开可以细分为：依赖管理、风险管理和问题管理。

（一）依赖管理

顺利完成一个项目需要具备各种条件，如需求、人力资源、时间、研发环境、测试环境等。当研发中心正式接受项目研发任务时，上述条件有些已经具备，有些已经确认可以具备，但总有些条件具有不确定性。这些未能确定的条件会影响项目的顺利完成，我们把这些未能确定的条件称之为依赖。

依赖管理其实是风险的早期识别管理。除了应该能够把所有未能确定的前提条件识别出来，更关键的是制定落实这些条件的措施，并监控这些措施的执行。

如果我们能够把所有未确定的条件都识别出来，能够制定并且落实所有的应对措施，且这些措施都有效，那么，项目必须的前提条件都可以具备。理论上，项目的后续过程应该再没有什么风险可言，项目如果还不能顺利完成，只能说明研发中心的主观努力不够。

根据统计，每千功能点的项目依赖条件一般有5-10个。少于这个数量，风险前期识别可能不足;多于这个数量，项目完成的条件就可能不足。

（二）风险管理

当我们事先没能识别所有的依赖或者制定和落实的依赖应对措施无效，项目需要具备的条件在接近临界点时还未能具备，这时就会形成风险。

所谓风险，就是存在将会影响项目进度或质量的问题。如果这些问题在预定的时间内不能化解，就会影响项目的进度或质量。

项目风险分为可预见风险和不可预见风险。可预见风险是前面所说的依赖，项目组要对所有可预见风险事先有对策和措施，项目管理的要点是对策和措施的落实。对于不可预见风险，项目组一方面要吸收教训和积累经验，在今后的项目管理中尽量避免出现不可预见风险;另一方面要马上采取措施化解风险。

项目风险还分为内部风险和外部风险。内部风险是由研发中心内部的客观或主观原因造成的。客观原因包括研发中心内部研发环境或测试环境不完备、研发中心内部人力资源不足、结构性不平衡等，主观原因有研发中心的管理水平和研发人员的素质等。这些风险，要通过加强内部管理、内部协调沟通解决，相对可控。外部风险主要是涉及一些外部原因，如需求问题、必须的软硬件采购问题以及外部研发环境、测试环境等，这些风险相对不可控。如果要解决的这些问题超出研发中心的能力，要把问题汇总，与相关部门沟通解决。

按统计，每千功能点的项目风险数不应该超过两个。另外，我们希望所有的风险均在前期依赖管理中识别出来，不要出现无依赖识别的风险。通常，无依赖风险应该控制在总风险的5%以内。如果上述两个指标超标，均说明项目管理前期的依赖管理可能有问题。

（三）问题管理

当风险未能在约定的时间内化解，风险就转化为问题。此时，项目已经受到实质性的损害。

对于问题的管理和对策，也有多种策略：

维持项目需求基本功能目标不变，继续努力化解风险，争取项目按期发布。但由于问题的存在，项目的进度受损，因此最好的结果就是风险在项目发布前最终解决，使项目能如期发布。但这样项目质量不可避免会受到影响。

根据风险解决的时间，顺延项目发布周期以保证项目质量。如果风险难以在短期内解决，应立即评估问题造成的损害程度和影响点，修改或减少项目需求目标，以规避风险。

暂停项目，视日后情况进展而定。对于这种情况，应该是在项目立项的可行性分析阶段对项目可行性分析不足，或者项目依赖条件有了很大变化所致。

按统计，每千功能点的项目问题数应控制在0.1个以下。超过这个数，整个项目的可行性分析和风险管理就会有问题。

四、变更管理

在研发中心软件研发项目管理中，有许多因素会影响项目的质量。但在某一段特定的时间内，一些因素相对固定，且不容易简单改变(如研发中心的管理水平、研发人员的素质、研发的软硬件基础设施环境等)。排除上述因素，还有三大因素会对项目质量造成影响：一是项目人力资源投入是否足够;二是研发周期是否合理;三是需求变更是否在可控范围内。

需求变更有多种原因。从软件生产的特点分析，需求变更是不可避免的。问题在变更的数量、变更涉及的规模与变更的阶段。通常是，变更越多，规模越大，时间越往后，变更带来的额外工作量越多，给项目造成的损害越大。其中特别是需求变更提出的时间越靠后，代价越大。

不同阶段变更的不同影响如图4所示。

从图4可以看出，相同的功能需求，在需求分析阶段前提出的权重为1。如果到了应用设计阶段提出，要完成该变更功能的工作量将比该需求在一开始就提出来多一倍，如果在集成测试阶段提出，工作量将是原来的6倍。如果到验收测试阶段才提出，工作量将是原来的10倍。通常，把项目周期内各阶段接收到的所有同意纳入当期项目实现的变更，其所需的工作量加权合计，称之为综合变更工作量，其对项目的影响称之为综合影响。

特别令人沮丧的是，变更恰恰一般都在比较靠后的阶段才提出来。因为越是到后期，越能看到项目的成果，就越能发现原来需求的不足。出于完美主义，是谁都有变更的冲动。

在整个研发周期里，变更数量如图5所示。

举例说明，如果一个项目经评估，其功能点为1 000;在应用设计阶段提出一个变更，其功能点为10;在集成测试阶段提出一个变更，其功能点为20。则

加权合计功能点=10×2+20×6=140

综合影响=140/1000=0.14=14%

结论是，3%的需求变更造成14%的影响。

变更管理的主要措施包括以下几个方面。

（一）事前充分考虑变更

由于变更是不可避免的，所以在编造项目计划时一定要把可能的变更开销考虑在内，特别是对于需求质量不高的项目。通常可以把变更的综合影响预计为10%以内。如果最终综合影响超过预计的数量，肯定会对项目的进度或质量造成影响，可以认为项目前期的需求和需求分析有问题。

（二）科技研发团队加大项目前期的投入

为了尽量减少变更及其带来的影响，科技研发人员一定要尽量加大项目前期需求分析的投入，应该与业务部门深入讨论需求的可行性、前瞻性，尽量落实需求的每一个环节。

（三）业务需求部门积极参与整个研发过程

软件工程与其他任何工程一样，随着工程的深入和具体细节的落实，需求的完善不可避免。为了能及时发现问题，提出问题，并及时修改问题，应尽量把变更提前，需求部门也应该在整个科技研发过程中加大投入，并积极参与，了解各研发过程的成果。

（四）严格限制后期变更

对于比较后期的变更需求要严格限制，最好能将其作为下一个项目的新需求。如果一定要在当前项目实现，要认真分析其对项目造成的影响，充分意识到其对项目的损害，把损害控制住能够接受的范围之内。否则，就要延后项目交付的时间。

（五）采取敏捷开发方式

篇4：课程研发的使命与职责

一、课程研发的基本方法

如果把课程本身比作一棵树，我想课程必须向内扎根，向外开枝散叶，向内指向师生生命的深处，向外直面周遭的环境。这两者是相互促进、相辅相成的。只有枝叶不断地进行光合作用，根才具有扎向深处的力量；只有根不断地输送水与养分，也才能枝繁叶茂。

在课程研发的过程中，我们必须敏锐地关注身边的自然环境和人文环境，敏锐地捕捉课程研发的契机。研发卓越课程不是在国家课程、地方课程之外不断地扩张，简单地做加法，它必须扎根于学生生存的土壤，面对学生生存的环境，捕捉社会生活对学生素质的不断增长的需求。比如说北方一些地区的雾霾、各大城市交通的拥堵，甚至巴黎的恐怖事件，这些都是研发课程的契机，都可以作为课程的主题和内容。

这样的课程才是从生活中来的，这样的课程是与我们教师和学生的生命、生活紧密相连的，它扎根在师生的心灵之中。它不仅仅是让学生去了解发生在自己生活周边的事情，了解其起因和过程，思考怎么面对这些事情，更重要的是让学生具有一颗敏感的心。现在很多人是盲目的，觉得生活中的许多事都与自己无关。“一枝一叶总关情”，我们一定要帮助师生懂得“天下兴亡，匹夫有责”的道理，明白社会上发生的一切都与“我”有关。因此，表面上看来雾霾、拥堵、恐怖事件与我们关系不大，但事实上与我们每个人都密切相关，与我们的教育有关，与我们的课程有关。

二、课程研发如何更有效地利用现代技术手段

如今，科学技术的发展日新月异，不断地改变着我们的社会、环境和教育。事实上，以前很多习以为常的事情，在现代科学技术面前都已经悄悄发生了改变，而且这种变化是广泛而深刻的。

我最近一直在思考未来学校和课程的样态。

在原始社会里并没有学校，因为那时采用的教育方式处于传播学所说的表演阶段，意思是说那个时候的教育是表演性的，是由长者与下一代面对面、人对人，通过手势、语言耳提面命进行的。

后来，有了学校。大约在公元前3500年，在巴比伦的两河流域的苏美尔人创造了楔形文字和泥板书供人阅读；到了公元前2500年左右，古埃及出现了宫廷学校，这些都是最初学校的雏形。当时，教育处于传播学所说的表述阶段，即可以借助于符号传递信息，不需要完全通过口耳相传的方式进行。这实际上为后来学校的课程提供了一个最初的样本。

近代学校伴随着工业革命的兴起而产生。因为工业革命的兴起，需要有更多高素质的劳动者，才能够适应机械化的生产，所以，它需要有规模更大的学校。夸美纽斯的大教学论和班级授课制，正是在这种时代背景下产生的。学校真正像现在这样有固定的班级、统一的教材、统一的大纲、统一的上课时间，其实也只有几百年的历史。

到了20世纪60年代，世界上出现了一个很著名的理论叫“学校消亡论”。这一理论的出现有两个很重要的背景，一个就是他们认为学校教育不能够真正实现教育的使命，学校对于培养优秀才人起不了太大的作用。还有一个很重要的理论，就是当时美国流行的行为主义理论。斯金纳作为行为主义学派的重要代表人物，提出了“教学机器”的概念。因为当时计算机虽然已经开始出现，而互联网还没有出现，但斯金纳已经天才地预见了现代互联网时代的网络教学方式，还提出了教学步骤。他当时提出了小步骤教学，就是教学要分成若干单元，一个一个单元地学习，由学习者自定步调，及时反馈。这些恰恰是当前互联网翻转课堂最基本的理论依据。

然而，50年过去了，学校不仅没有消亡，还在不断地发展。我们不仅要追问，未来的学校会怎么样？我认为未来的学校可能不会消亡，但一定会被改造。未来的学校可能不叫school，而是叫learning center（学习中心），可能不再需要按时到学校去上课。我曾听一个芬兰的教授说他的孩子上午十点钟才上学，下午两点钟就回家了。学生在学校就三四个小时，能有多大的作用？实际上，现在大部分的知识和学习内容，完全可以通过各种媒介获得。未来的学生大部分的学习可能是在社会、网络及家庭中进行的。

所以，我们这些做教师、做校长的，要有一点危机感。如果你的学校不能成为一个真正吸引人的学习中心，以后还会有人到你的学校来吗？我曾经动员我的一个朋友赶紧去组建一个学习中心，为未来学校做个模板，作为一种教育创业，定会很有竞争力。美国现在在家学习的人已经很多了，在家学习通过验证、考试后，政府就给他发文凭。美国有相当数量的人在网上学习，也有很多网上学校，可以发文凭。既然人们可以从网上学校获得文凭，为什么还要到学校来呢？他完全可以在家里好好地睡一觉，醒了以后学习，头脑清醒，精力充沛。这样的学习多好，为什么一定要像现在这样，几十分钟坐在课堂里呢？如此完全可以实现定制化，可以跟老师约时间：“老师，我想在星期五、星期六的14点，跟你讨论一下数学的分数问题。”“老师，我想在星期三的下午，跟你讨论一下怎么演讲更能够吸引人。”倘若如此，教师就成为一个成长伙伴和指导者，不需要系统地、按部就班地把知识从头讲到尾。今后大部分的课程完全可以到网上去学，还需要那么辛苦地走读吗？

不久前，我来到河南郑州市管城区的创新街小学，在看了现场展示后，我发现很多课程是没有必要让教师开的。如今社会资源那么多，很多教师跟人家专业人士比，功力差得远了。这些活动课程，我主张利用社会资源，尽可能请名家大师讲课，而让教师成为课程的组织者、联络者、驱动者。当然，这不是打击教师的积极性而可能是更好的课程研发方式。教师参与课程研发是一件非常好的事情，因为这不仅是对自身的提升，也是一种快乐，而且是师生活动的一种方式。但严格来说，活动课程主要是活动，它活动的成分大于课程的成分。

我认为，未来的学校和教育有许多问题是很值得我们去思考的。首先是教育本身变了，或者说教育变成学习了，教育的活动实际上是学习的活动，所有的教育都是为了学习展开的。学校是学习的地方之一，教室现在叫classroom，以后可能就会变成learnroom，或者是studentroom了。所以，学校教育将会真正走向定制化、个性化。当然，义务教育阶段的课程最好还是由国家研发，给大家无偿地配送。8年前，我就建议教育部建一个国家教育资源平台，由国家购买、提供教育的公共服务产品，给每个学校提供尽可能多的高质量课程资源，让大家分享。我始终认为这可能是一个方向。

三、怎样保持课程逻辑的自洽性

研发课程，逻辑的自洽性是很重要的。我们现在已经进入一个“碎片化”的时代，所有的信息基本上都是碎片化的。碎片化是我们这个时代的特征，同时也成为我们学习的一个障碍。在研发课程的时候，同样也是如此。

我一直认为，课程也好，教育也罢，是有自己的逻辑和体系的。现在很多学校似乎变成了一个“大杂烩”，没有中心，没有灵魂，没有文化。我认为课程应该有自己的自洽性。我们“新教育实验”的课程为什么要提出这样一个架构？基础是生命课程，因为教育是为了生命而存在的，生命至上，公民课程、艺术课程、智识课程，再加上个性化课程，这个课程架构是一个非常严密的体系。

比如，我们已经审视过艺术教育。艺术教育并不是我们提出来的，但我们新教育的艺术教育完全不同于传统艺术教育的概念。传统艺术教育简单地分为美术课程和音乐课程。我们认为，整个教育都应该是艺术的。艺术是一种精神、一种情怀，也是一种方法。它能帮我们更好地用艺术的眼光看世界，能帮我们更好地创造一个新世界。这就是艺术的作用。所以，我们研发出很多综合性艺术课程，比如读写绘、生命叙事剧等。今后，美术、音乐课程也要有自己的逻辑，什么时候学什么内容，从哪里开始学，这些问题都要经过科学研究，要根据人的身心发展规律来安排教学内容。虽然任何知识都可以在任何时候，用合适的方法教给任何年龄的儿童，但不管怎样，在人的成长中不同学习内容有不同的最敏感期，在最敏感期教给学生最合适的内容，是教育应该关注的。

奥地利教育家鲁道夫·史代纳于1919年在德国创立第一所华德福学校，历经90多年的发展，如今华德福教育已成为世界上规模最大、发展最快、非宗教的独立教育形态，华德福学校遍布全球不同文化背景和社会价值观的国家。华德福教育主张跟着人的心灵走，跟着人的身心发展规律安排教学的内容。这也是华德福教育最本质的东西。而我们现在的课程还没有完全根据人的身心发展规律安排内容，更多的是考虑学科自身的内在逻辑性，而科学家发现世界的规律与人们认识世界的规律并不完全一致。

比如，关于历史的学习，学生到中学才开始上历史课，而且历史课仅仅给学生传授历史事件的时间、人物、地点、背景、过程、意义。如果应对考试，学生只要掌握这6个要素就够了。这样学历史，就把历史仅仅作为知识记忆了。我认为，真正的历史教育应该让人成为一个有历史感、有历史情怀、有社会责任感的人。每个人都在书写自己的历史，每个人怎么写自身的历史，会影响我们如何书写人类的历史。这是历史教育的根本任务。2015年暑假，我组织了7个全国优秀的历史特级教师工作室，召开了一次小型的研讨会。我们正在编辑新教育的新历史读本，计划从小学就开始学历史。这个历史读本有望不日正式出版。我们研发课程就是要做这样的事情，我们不要求所有的学校都做这样的事，但我们的专家团队一定要为大家提供引领。

再比如，我们新教育做了多年的晨诵课程。我们正在梳理自己的晨诵理论：为什么要做晨诵？什么样的晨诵才是好的晨诵？晨诵怎样才能完全契合儿童身心发展的规律？怎样才能把人类最美好的东西真正教给孩子，让中国文化最根本的精神扎根在孩子的心中？这些都是我们要解决的问题。

总之，课程是我们学校教育的核心，是培养人的重要渠道。有什么样的课程就有什么样的教育生活，有什么样的课程就会培养出什么样的人。课程研发要从碎片化的思考，转向系统化的架构。我们应该把所有的课程打通，让课程真正融入师生日常的生活，让教育真正成为师生过上一种幸福完整生活的基石。

篇5：研发会计的职责内容

2、负责游戏素材测试的合同、付款审核、对账确认;

3、协助美术外包人工成本预提方案的开展及后续自动化事务的跟进;

4、负责固定资产模块合同、付款及入库表的审核，确认资产采购的合理性、真实性;

5、参与固定资产盘点;

6、负责美术外包、固定资产、游戏素材测试费等账务处理工作;

7、配合审计资料的提供;

8、跟进公司设立及注销的相关财务事项;

篇6：研发会计的职责内容

2、从财务角度跟进研发项目支出的立项、费用归集、研发支出资本化等相关工作;

3、复核研发人员工时分配表，归集研发部门领料及其他各类费用支出，并进行账务处理;

4、编制研发支出台账，与研发管理部门进行研发预算按月对账，编制研发预算与投入

对比表;

5、按月与研发部门核对各个研发项目，了解项目进度，对已经结束的项目根据研发部门提

供的资料进行账务处理;

篇7：研发会计的职责内容

2、负责在建工程管理，无形资产管理，长期待摊费用管理;

3、负责研发支出管理。包括统筹管理研发立项与支出预算，做好研发项目立项申请、计划书等归档工作;

4、定期完成量化的工作要求，并能独立处理和解决所负责的任务;

篇8：研发管理部的职责

在论及研发团队的管理时, 一些学者从团队的生命周期角度来考察, 如陈春花 (2002) 将科研团队分成酝酿期、组建期、运作期和解体期继而分析各个阶段的主要管理任务;更多学者从组建、协同、激励、冲突管理、知识管理等几大模块分别进行阐述。他们主要把视角放在研发团队的内部, 至于团队外部的管理工作, 尽管有所涉及, 但是并没有被单独提出来以强调其重要性。

早在二十世纪七八十年代, 西方第二代研发管理已将战略纳入研发团队的管理之中, 他们通过使业务部门或公司成为研发专业人员的外部客户, 增强业务部门与研发团队之间的沟通和协同, 并对每一个研发项目都综合考虑项目生命周期内的成本、对业务的影响、项目的不确定性以及项目综合管理和运行 (Nobelius, 2004) 。而在我国企业中技术研发部门一向是“管理的黑箱”, 只看到投入产出, 看不到里面发生了什么。这样的无为而治, 对企业来说相当危险。因此, 笔者认为企业必须要重视研发团队的外部管理。本文所述研发团队的外部管理, 是指企业的高层管理者包括人力资源等部门对因研究开发需要而临时组织的研发团队及研发活动给予引导性、辅助性管理工作。

二、企业如何做好研发团队的外部管理

企业的领导者不能企图通过为研发团队提供足够的研发资金、资源后就坐等收获, 他们需要密切关注那个“黑箱子”, 关注其信息的输出, 并输入适当信息。笔者认为企业需要从以下几个方面做好研发团队的外部管理工作。

1. 建立双向沟通模式

有关研究表明, 管理中70%的错误是由不善于沟通引起的。有效的沟通, 可以使企业上下人际关系和谐、工作环境融洽, 能及时发现并解决企业中存在的各类问题, 从而顺利完成工作任务, 取得绩效目标。在一个团队之内, 沟通绝不能只是单向的, 必须是一种双向互动的形式。因为, 只有团队成员与团队高层之间建立无障碍的通话渠道, 这个团队才是健全的, 才能够真正地携手共进。进一步地讲, 研发团队与企业内其他组织也需要建立畅通无阻的双向沟通渠道, 使各自清楚彼此的工作进展以及资源需要, 这无疑会增强团队的研发实力, 进而增强企业的竞争力。

对于研发人员, 管理者和研发人员沟通时给予研发人员平等的地位, 让其感觉到自己得到了重视, 这样才能促使其说出真实意见和建议, 才能为公司的发展奉献一切。建设完善的沟通制度和系统, 拥有畅通的信息流通系统、反馈系统, 强调双向沟通和把沟通制度化, 这是一些优秀企业的共同特征。

2. 对研发人员进行适当的激励工作

美国学者布朗提出, 对于从事知识性工作的人而言, 他们对赏识、赞许、成就方面的关注远胜于其他的激励形式。强化工作本身的激励作用, 信任、尊重与支持以及准确的绩效评估与奖赏都是很好的激励方式选择。

首先, 要根据研发人员的技能和特长把他们放到研发团队中最合适的位置上, 即让工作和能力作到最佳匹配, 这是工作激励的前提。其次是企业要为研发人员提供具有挑战性的工作, 这样一方面可以保持本公司的技术领先性, 另一方面研发人员也得到了锻炼和成长。最后, 企业领导要对研发人员的工作给予充分的肯定, 以满足研发人员的较高的受尊重的需求。此外, 还可以给予优秀的研发人员一定的荣誉称号或者采用研发成果署名制的方法来增加他们的工作成就感和荣誉感。此外, 企业还可以借助拓展研发人员的晋升空间来达到激励效果。借鉴国外管理经验, 企业可以为研发人员提供双重职业生涯通道, 即管理生涯和研发生涯通道。

3. 做好监督控制工作

监督是一个随着时间推移来评估内部控制运行质量的过程, 它能确保内部控制持续、有效地运作。监督必须由适当的人适时评估内部控制的设计和运作, 并采取必要行动。它包括持续监督与个别评估两种方式。持续监督存在于正常的营运活动中, 包括例行的管理和监督活动;个别评估的范围和频率取决于风险的大小和控制的重要性。企业项目投资中的监督就是及时收集项目投资过程中的有关信息, 并与计划目标相比较, 从中发现项目投资过程中可能或已经出现的问题, 以便及时采取措施解决问题, 保证项目按计划顺利实施, 最终达到预定的目标。为保证监督效果, 项目监督应实行内外结合, 同时, 项目监督应是全过程、多渠道的监督。

三、结论

本文基于研发团队的外部角度, 建议企业管理者从创造企业的公平工作环境、建立双向沟通模式、激励和监督控制四个方面对研发团队进行外部的辅助管理, 最大限度地帮助团队实现研发目标。本文一大缺点在于它仅仅是理论演绎的结果, 缺乏实证的支持, 寄希望于通过更科学的方法找到切实有效的研发团队管理模式。

摘要：本文将企业研发团队之外的企业组织作为研究视角, 分析了企业研发团队之所以需要外部协调管理的几点原因, 并从沟通、激励和监督三个方面强调企业外部管理的事实。

关键词：企业研发团队,外部管理,激励

参考文献

[1]陈春花叶飞:科研团队生命周期管理的理论框架研究[J].科技管理研究, 2002年第3期

[2]杰恩川迪斯著:研发组织管理[M].知识产权出版社, 2005