研发团队管理

2024-07-02

研发团队管理(精选6篇)

篇1:研发团队管理

研发团队管理

长城企业战略研究所 安逸 王缨

2004-4-7

为什么研发团队的管理很重要?

新产品开发日益成为企业成功经营的核心。持续推出新产品将使企业立于不败之地,而卓有成效的新产品开发取决于优秀的新产品开发团队。人们的共同结论是“有什么样的开发团队就有什么样的新产品”这可以说是一条定律。大至一个企业的新产品开发活动质量,小到一个具体的新产品开发项目的质量,接触和评估其团队都是最直观、最有效的方法。对新产品开发团队的评价来源于相互作用的三个方面:团队中的个人、团队机制和团队文化。对于企业的高层管理者来说,他们当中的很多人并不是产品专家,他们对于新产品开发的管理更多地体现为对新产品开发团队的管理。

新产品开发团队的组织形式是由新产品开发项目的性质决定的。开发团队的组织原则是:开发项目越复杂,对企业的意义越重大,开发团队就越独立,就越需要减少企业日常工作的影响。对于消费品企业,开发团队一般有以下三种类型(见表1):

中外管理 研发团队有哪些形式?

表1 新产品开发团队类型

新产品项目性质

新平台产品开发

完善现有产品线

产品技术改进 团队类型 独立的专职团队 跨部门临时团队 技术改进团队 团队特点 管理要素 独立于企业日常运营 保持独立性财务目标 开发工作与其他日常工作并行 部门协调机制范围最小,方式灵活 把握项目运行的时机

“跨部门临时团队”的组织形式是在消费品的新产品开发中最常见的、基本的组织形式,于管理的组织形式。说它“基本”,是因为在其它两种团队类型的早期,经常以“跨部门临时团队”的形式出现;说它“难于管理”,是因为部门之间存在着观念和信息的“壁垒”,这些壁垒很难打破,而打破这些“壁垒”,恰恰是新产品开发管理的关键。正是基于以上原因,“跨部门临时团队”是我们论述的重点。在很多高技术企业,技术开发团队多采用独立的专职团队形式。开发人员被“关”在一个舒适的、“与世隔绝”的空间里,在特定的时间内展开“科研攻关”。

建设开发团队的工作机制,其目的在于沟通信息、明确责任、协调进度。工作机制可以分为两种:正式机制和非正式机制。正式机制多体现为团队会议,非正式机制则是不同部门的开发人员之间的随机交流。在很多消费品生产企业,新产品开发项目的主要责任者是市场部门和研发部门,因为他们是新产品的设计师、知识源和“专家”。开发团队的工作机制首先是这两个部门的协调机制,然后才是由这两个部门主导的团队工作机制(见表2)。研发团队如何形成好的机制?

表2 新产品开发团队的工作机制参与部门 主要内容 备注

有些

企业

叫做

“新产

品开

发委长期坚持。员

会”,范围

也有

所扩

大。关键

研发-市场部门市场部、研发部定期交流所有项目情况,确定开联席会门 发方向,产生新项目。议 在某个项目里程碑完成后评估项项目运完成情况的可项目组所有成员 目运行情况,做出下一步的安行会议 靠性。排。

避免

犯同

样的错

项目回项目完成或终止后对项目整体运真正明确失败误,项目组所有成员 顾会议 行的总结。原因。形成指示

和经

验积

累。

项目每一阶段结束后汇总项目运总结报市场部或研发部保证决策信息行情况,并发给每位项目组成告制度 项目经理负责 的真实性。员。

对于那些非正式的团队机制是不好用制度规定下来的,非正式的团队机制在很大程度上受到团队文化的制约。

新产品开发团队文化是企业整体文化的组成部分,因此新产品开发团队文化具有企业文化共有特性,又有它的独特性和自身要求(见表3)。

如何建立研发团队文化?

表3 新产品开发的团队文化

新产品开发活动的特点 新产品开发团队文化要求

创新性

协同性

风险性

时间性 鼓励原创性的工作 鼓励随时随地通畅的交流重视细节和不同意见强烈的时间观念和责任意识

观察新产品开发团队文化最有效的方法是“听”,听听他们在交流中说些什么,是否符合新产品开发活动的内在要求。如果没有好的团队文化,新产品开发过程中就会出现一些莫名其妙、看似荒唐但却是不可挽回的严重失误。很多企业的研发经理为这些失误感到苦恼,但他们往往在失误本身上找原因,却没有看到隐藏在失误背后的不健康的团队文化。新产品开发团队文化与新产品开发所需要的专业知识和技能无关,但是它却深刻地影响着新产品开发工作的质量,甚至可以说是团队文化塑造了新产品。在很多美国公司,高级的研发领导人甚至没有技术背景,但他们依然可以卓有成效地领导产品研发,其中一个重要原因就是他们有能力塑造一个优秀的研发团队文化。塑造团队文化的最好方法是企业高层管理者的率先垂范和团结一致,而不是期待基层开发人员的自觉。一家公司的高层采购经理认为,产品开发所需新原科的采购在他的工作中并不重要,重要的是现有原材料的采购维护;一家公司的生产总监认为,新的生产工艺会破坏现有的生产秩序,所以需要抵制;一家公司的技术总监认为,他的责任只是产品开发成功,至于主动组织新产品知识培训则不是他份内之事;一家公司的总经理问道,为什么开发人员总是不切实际,异想天开?这些企业的高层经理抱有这样的观点,新产品开发团队文化也就可想而知了。所以,建设良好的新产品开发团队文化,需要高层管理者从自身做起。

除了把握企业战略和产品方向外,总经理对新产品开发活动的管理在很大程度上体现为对新产品开发团队的整体管理。总经理很难深入新产品开发的技术细节,但在中国企业中(尤其是民营企业),总经理对新产品开发工作影响巨大。对这个问题的探讨,具有极为重要的现实意义。总经理如何管理研发团队?

建议总经理对新产品开发团队的管理应注意:

(1)容忍创新的“健康失败”。鼓励创新首先意味着有创新的意愿,其次意味着容忍“健康的失败”。所谓“健康的失败”是指那些付出了真诚努力的失败。产品创新的历程从来不是一帆风顺的,某一点的改变可能会引起连锁反应,“牵一发而动全身”。改变固然会有失败的可能,但不改变就不会有成功的新产品。在一个“动辄得咎”的环境里,不能想象产品创新的成功。总经理对产品创新的影响首先在于培育一个创新受到鼓励的环境。

(2)培养“专家意识”,减少对开发细节的干涉。产品创新的专家首先是那些敢于对产品创新负责任的人,其次才是拥有丰富产品创新经验的人。在企业里经常发生没有人敢于对产品开发负责的现象,决策“议而不决”,然后由总经理判断而“定于一尊”。企业家不是神,不能洞悉一切风险,这种决策方式从一开始就孕育很大的风险。总经理需要明确责任,鼓励负责任的勇气,才可能在企业内部培养出“专家”。

(3)打破技术部门的壁垒,重视专业的横向交流。技术部门在中国企业中一向是“管理的黑箱”,只看到投入产出,看不到里面发生了什么。但技术过程对产品方方面面的影响极大。总经理应该鼓励技术部门走出“黑箱”,与市场、采购、财务乃至销售部门建立交流的机制,使技术部门看到他们的工作对企业其他部门产生了怎样的影响,而技术部门也会看到产品创新的广阔机遇。

(4)给开发人员开阔视野的见习机会。创新经常来自于换一个角度来看问题,来自于找到正确的基准。一年到头埋头于实验室的开发人员创新精神一定是不活跃的。给开发人员参观、学习、研讨的机会,回过头来审视自己的产品,就会产生新的认识,产品创意就蕴含在这些新的认识当中了。

篇2:研发团队管理

我觉得还是有时间得交流交流 【潜水】朱宏兵 2014-7-7 13:45:03

我感觉做管理和做技术差别很大 【潜水】朱宏兵 2014-7-7 13:45:30

做技术可以google,可以追求完美,但是做管理没法google,没法完美 【潜水】朱宏兵 2014-7-7 13:45:36

最近很郁闷啊

【潜水】玉兔 追月 2014-7-7 13:46:15

恩。可以简单说说问题吗

【潜水】玉兔 追月 2014-7-7 13:46:35

管理和人性、制度相关 13:47:46 【潜水】朱宏兵 2014-7-7 13:47:46

简单得说,举个例子啊,例如一个项目希望尽快出来,项目化运作,项目化以后,代码质量如何保证,如何保证代码的后续可维护性,我现在就觉得很难做 【潜水】朱宏兵 2014-7-7 13:48:20

大家还有认识的搞一线开发管理的,多邀请一些来,有空聊聊天呗

【潜水】玉兔 追月 2014-7-7 13:48:31

恩。好的

【潜水】玉兔 追月 2014-7-7 13:49:04

代码质量一靠培训+规范,二靠测试。

【潜水】玉兔 追月 2014-7-7 13:49:19

看看腾讯他们如何保证的 【潜水】朱宏兵 2014-7-7 13:49:34

没看到相关资料 13:49:51 【潜水】朱宏兵 2014-7-7 13:49:51

网上基本华为的居多,【潜水】玉兔 追月 2014-7-7 13:50:00

有同学在腾讯吗? 【潜水】朱宏兵 2014-7-7 13:50:07

也可能和我这方面花得时间有点少有关系 【潜水】朱宏兵 2014-7-7 13:50:15

有一个,没怎么联系 【潜水】钟白平2014-7-7 13:50:25

我觉得项目化就应该有相应的项目管理方法论 【潜水】朱宏兵 2014-7-7 13:50:36

而且是不是做coding的,可能有点差距 【潜水】钟白平2014-7-7 13:51:15

比如敏捷项目管理等 【潜水】朱宏兵 2014-7-7 13:51:25

倒是有人在阿里,可以有空找人聊聊 【潜水】钟白平2014-7-7 13:51:44

不知道大家有没有这方面的管理经验 【潜水】朱宏兵 2014-7-7 13:51:51 敏捷感觉对这个用处不大 13:52:21 【潜水】朱宏兵 2014-7-7 13:52:21

没有,只看过几本敏捷的书

【潜水】玉兔 追月 2014-7-7 13:52:35

恩。多和BAT聊聊。相互交流。规范管理。【潜水】钟白平2014-7-7 13:52:38

方法都是可以灵活运用的 【潜水】朱宏兵 2014-7-7 13:52:58

嗯,那倒是

【潜水】朱宏兵 2014-7-7 13:54:04

不过,我倒是腾讯他们怎么建立起各种研发方面的制度,挺感兴趣的 【潜水】朱宏兵 2014-7-7 13:54:21

其实数数他们公司,也还没几年 13:54:39 朱宏兵邀请╃鬼公子╊加入本群 【潜水】朱宏兵 2014-7-7 13:55:16

戈兆万是和我一个公司的,做PC上软件开发 【潜水】╃鬼公子╊ 2014-7-7 13:55:29

大家好

【潜水】玉兔 追月 2014-7-7 13:56:19

大家好

【潜水】玉兔 追月 2014-7-7 13:56:25

贵公子 【潜水】钟白平2014-7-7 13:56:23

【潜水】戈兆万 2014-7-7 13:56:36

13:57:09 【潜水】玉兔 追月 2014-7-7 13:57:09

13:59:34 【潜水】王辉 2014-7-7 13:59:34

腾讯的代码质量都有指标的

【潜水】王辉 2014-7-7 13:59:42

比如bug 也是分级别的

【潜水】王辉 2014-7-7 13:59:48

都跟KPI挂钩

【潜水】王辉 2014-7-7 14:00:14

弄到腾讯的研发部KPI指标,可以参考参考 【潜水】朱宏兵 2014-7-7 14:00:17

一线员工搞KPI不合适吧?

【潜水】王辉 2014-7-7 14:00:31

腾讯全部都跟KPI挂钩 【潜水】朱宏兵 2014-7-7 14:00:52

一般说法,对一线员工搞KPI,基本必死无疑啊 14:01:55 【潜水】钟白平2014-7-7 14:01:55

搞KPI也要有人搞才行啊 【潜水】钟白平2014-7-7 14:02:59

小团队没有必要搞KPI的吧 14:04:16 【潜水】钟白平2014-7-7 14:04:16

老大将问题抛得更具体一些,我们大家一起讨论讨论 【潜水】朱宏兵 2014-7-7 14:04:23

我现在对项目化以后,代码结构等保证没有啥好思路,你们有啥建议吗? 【潜水】朱宏兵 2014-7-7 14:04:53

别叫老大,不敢当

【潜水】王辉 2014-7-7 14:05:36

你说的项目化是指基本产品已经完成,具体根据工程项目修改部分模块吗? 【潜水】钟白平2014-7-7 14:05:34

应该需要有一个代码架构设计专家来帮着把关 14:08:00 【潜水】朱宏兵 2014-7-7 14:08:00

具体来说,就是现在要开发一个下一代产品。我们现在基本上是基于小组的,所以个人负责一部分产品线/功能。现在想往项目化走,但是我对于项目化以后如何保证代码的可扩展性之类的心存疑虑 【潜水】朱宏兵 2014-7-7 14:09:12

如果真正项目化走,以项目进度为目标,我总担心会很难让人去保证代码兼容扩展等需求了。【潜水】朱宏兵 2014-7-7 14:09:45 我们要做的是一个新的基础平台,可能以后会在这个上面做扩展开发 14:10:03 【潜水】钟白平2014-7-7 14:10:03

是的,我们就有这样的问题,需要有一个项目团队对软件架构负责

【潜水】王辉 2014-7-7 14:10:18

恩。那就多留点时间在架构上多考虑考虑

【潜水】王辉 2014-7-7 14:10:41

项目进展中也要加上架构讨论部分。【潜水】钟白平2014-7-7 14:10:47

总要有人把控全局 【潜水】朱宏兵 2014-7-7 14:10:55

@钟白平你是指另外一个团队对架构负责? 【潜水】朱宏兵 2014-7-7 14:11:01

审批架构? 14:12:39 【潜水】朱宏兵 2014-7-7 14:12:39

你们现在代码管理用啥? 【潜水】钟白平2014-7-7 14:12:50

审批应该还不够,最好是能参与架构设计,让每个项目团队中的骨干参与设计并审批架构设计 【潜水】朱宏兵 2014-7-7 14:13:09

我们现在svn,感觉提交后审核这块似乎svn不能满足需求 【潜水】朱宏兵 2014-7-7 14:13:49

我感觉架构设计人多了,应该不好弄 【潜水】钟白平2014-7-7 14:14:20

那至少也要让大家达成统一意见 14:15:29 【潜水】钟白平2014-7-7 14:15:29

开发人员在什么都不知道的情况下,代码的兼容与扩展是很难做到的

【潜水】王辉 2014-7-7 14:15:55

恩。每个项目团队中的骨干参与设计并审批架构设计。是个好办法。【潜水】朱宏兵 2014-7-7 14:16:04

肯定不会什么都不知道。【潜水】朱宏兵 2014-7-7 14:16:38

其实理想情况应该是架构师先做好架构设计 14:17:57 【潜水】钟白平2014-7-7 14:17:57

是啊,【潜水】朱宏兵 2014-7-7 14:17:59

你们在实际项目中先找骨干做完架构再写代码吗?先做 【潜水】钟白平2014-7-7 14:18:09

团队中有个架构师是最好的 【潜水】朱宏兵 2014-7-7 14:18:14

我们还没有这么搞过 【潜水】钟白平2014-7-7 14:18:29

恩,我们先做架构,再做开发 【潜水】朱宏兵 2014-7-7 14:19:29

架构和开发的人员是分开的? 14:20:06 【潜水】朱宏兵 2014-7-7 14:20:06

还是同样的人员,先做一样,再做一样 【潜水】钟白平2014-7-7 14:20:18

没有完全分开,做架构的人也做开发 【潜水】钟白平2014-7-7 14:20:38

先做整体架构,然后再分开开发 【潜水】朱宏兵 2014-7-7 14:21:13

嗯,我也试试。如果碰到什么问题再找你讨教 【潜水】钟白平2014-7-7 14:21:32

我们也在摸索呢

【潜水】朱宏兵 2014-7-7 14:21:40

【潜水】朱宏兵 2014-7-7 14:22:05

代码管理你们都用啥? 14:22:18 【潜水】钟白平2014-7-7 14:22:18

我们用svn 【潜水】朱宏兵 2014-7-7 14:22:25

SVN?我感觉SVN代码审核很难做啊 【潜水】朱宏兵 2014-7-7 14:22:48

没审核的代码先提交到某个分支? 【潜水】朱宏兵 2014-7-7 14:23:25

还是直接直接提交,不对再打补丁? 【潜水】钟白平2014-7-7 14:23:27

提交前审核

【潜水】朱宏兵 2014-7-7 14:23:56

就是线下先交流了? 14:24:45 【潜水】朱宏兵 2014-7-7 14:24:45

那你给他们提交的权限吗?我感觉一旦给了,很难保证他们先提交前会找人审核 【潜水】钟白平2014-7-7 14:25:03

恩,每天都有一点时间做交流 【潜水】钟白平2014-7-7 14:25:40

项目负责人或者高级程序员或者小组负责人,负责审核 14:27:14 【潜水】朱宏兵 2014-7-7 14:27:14

我们小组不太理想,给了提交权限以后,提交审核基本没做成 【潜水】钟白平2014-7-7 14:27:45

责任分配不到位吗? 【潜水】钟白平2014-7-7 14:28:00

我们的每个人都有自己的责任 【潜水】钟白平2014-7-7 14:28:15 项目开始前有个责任分配矩阵 【潜水】朱宏兵 2014-7-7 14:28:24

嗯,我们责任划分不清晰 【潜水】朱宏兵 2014-7-7 14:29:03

那你们基本规定好了各个人在项目中的各项权限了吧 14:29:56 【潜水】朱宏兵 2014-7-7 14:29:56

有点事,离开会儿 14:43:22 【潜水】戈兆万 2014-7-7 14:43:22

代码的review个人向试行下面办法,大家可以给点意见;基本思路是类似开源软件的模式,个人向提交代码,就发补丁包给review者,review通过由review者commit,否则退回;review者基本靠交叉review原则产生,不集中到leader头上;

有想法review应变成集体性的,而不是指定某个人的,只要指定时间内有人review过就可以;发现问题有对应奖惩;【潜水】钟白平2014-7-7 14:45:12

这个办法很好啊,14:48:11 【潜水】戈兆万 2014-7-7 14:48:11

我也觉得可以试试 14:51:22 【潜水】朱宏兵 2014-7-7 14:51:22

这个问题在于提交者显示问题 【潜水】朱宏兵 2014-7-7 14:51:47

例如A做的功能,提交后显示是B提交的,体现不了A 【潜水】戈兆万 2014-7-7 14:52:26

B的提交理论上应该总是代表A,反之A代表B;我觉得没问题的 14:57:29 【潜水】戈兆万 2014-7-7 14:57:29

或者最直接review者commit时在注释中标明提交review的就行了,反正中国人名字也不长

15:00:32 【潜水】朱宏兵 2014-7-7 15:00:32

群体Review,还有C存在 15:13:17 【潜水】戈兆万 2014-7-7 15:13:17

有C存在 什么意思? 15:15:24 【潜水】钟白平2014-7-7 15:15:24

谁提交谁就有责任 【潜水】钟白平2014-7-7 15:16:08

其实代码审查最大的功能是让开发人员知道将会有同事或者他很在意的人查看他的程序,那么他的编程态度就会不一样的,代码质量也会提高【潜水】戈兆万 2014-7-7 15:16:09 @钟白平

【潜水】钟白平2014-7-7 15:16:35

【潜水】朱宏兵 2014-7-7 15:16:50

我是说B和C都可能会Review A的代码

【潜水】朱宏兵 2014-7-7 15:16:59

这个我很赞同 【潜水】朱宏兵 2014-7-7 15:16:58

15:19:09 【潜水】戈兆万 2014-7-7 15:19:09

群体review目前只是想法 需要必要的软件工具支援才行 个人觉得这个方式会比单人review更有效;基于上面@钟白平的表达,最直接的增加了源码的读者数量 【潜水】朱宏兵 2014-7-7 15:20:49

戈兄的意思是结对Review? 15:21:28 【潜水】戈兆万 2014-7-7 15:21:28

是的 捉对编程 【潜水】朱宏兵 2014-7-7 15:22:00

你们小组准备搞这个? 【潜水】戈兆万 2014-7-7 15:22:22 是啊 【潜水】朱宏兵 2014-7-7 15:22:47

也不错

【潜水】朱宏兵 2014-7-7 15:22:52

15:29:09 【潜水】戈兆万 2014-7-7 15:29:09

篇3:研发团队管理

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

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

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

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

1. 建立双向沟通模式

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

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

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

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

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

3. 做好监督控制工作

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

三、结论

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

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

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

参考文献

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

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

篇4:研发团队管理

【关键词】社会关系网络;研发团队;人力资源管理

随着社会经济的发展,人力资源管理理念不断革新,尤其是在政府主张继续深化改革的大背景下,企业逐渐认识到创新的重要性。要想在竞争激烈的市场上立于不败之地,就要改变以往依靠资源实现发展的局面,将创新作为发展的驱动力,于是基于社会关系网络的各类研发团队开始受到企业重视,并成为企业人力资源管理的一部分。

一、社会关系网络概述

当前中国乃至世界经济的发展都进入了新阶段,创新型企业将引领社会未来发展方向,企业要想实现可持续发展,必须要将创新作为发展动力,因此企业需要注重提升员工以及研发团队的创新能力。社会关系网络就是企业发展的新视角,因为员工价值往往在团队中才能得以体现,任何一个员工都无法独立完成工作,其只有与周围的人互动,才能充分发挥自己的能力与精力,实现工作目标。一名员工的发展在很大程度上取决于其所处的社会网络和其与该社会网络的交往方式。社会资本形成的基础就是社会关系网络,其为信息交换与资源整合提供了依据,在研发团队中,交易成本更低、信息流通更加便捷,员工之间可以通过交流實现知识积累,提升创造力。

二、社会关系网络与研发团队人力资源管理实践的关联性分析

研发团队的人力资源管理实践一方面是为了开发员工的知识与能力;另一方面是为了整合资源,与社会关系网络建立联系。因此我们需要确认能够影响社会资本的人力资源管理实践有哪些,具体可以将影响因素分为以下三类:动机要素、员工能力要素与参与机会要素。

(一)从动机要素角度分析

所谓动机要素,就是看员工行为与工作目标之间是否保持一致,人力资源管理实践过程中,需要员工规范自身行为,为工作目标服务。以往在研究动机要素时,人们都比较关注福利待遇、绩效评估、流动晋升等,而在社会资本的概念下,则需要在没有明确回报或者没有立即给予回报的情况下进行工作,提供帮助者和接受帮助者都是团队内部员工,管理实践是产生这种动机的因素。研发团队要想将自身能力发挥到极致,就需要建立这种互惠关系,形成稳定的社会关系网络,团队中任何一名成员都可以在这一网络中获取自己需要的资源。

(二)从能力要素的角度分析

所谓能力要素就是提升团队人力资本水平的实践,员工以及团队的人力资本水平会在管理实践中有所提升。从以往的经验我们可以总结出,人员招聘、选择、培训以及试用等都属于人力资源管理实践,整个过程不仅要提升某个员工或者整个团队的知识与技能,更重要的是要思考如何将一名员工成功“嵌入”到整个团队中,要求员工有能力从周边社会关系中获取信息资源。而对于组织或者是团队内部而言,员工就是网络中的各个节点,员工的互动过程就是从周围节点获取资源的过程,也是为其他节点贡献资源的过程,基于社会关系网路的人力资源管理实践,就是要提升所有员工从节点中获取知识与技能的能力,具体有以下两点影响因素:一是员工的认知模式,如果认知模式不同,就无法识别和理解对方的知识,资源获取通常都会失败。因此在人力资源管理实践的过程中,需要建立一种共同的认知模式,各个网络节点之间能够做到相互识别、相互理解,为成功地获取资源打下基础;二是各个节点之间是否愿意交换知识,仅仅认知并理解是不够的,员工只有愿意分享自己掌握的知识与技能,才能实现资源获取、交换。因此在人力资源管理实践过程中,还要培养员工的分享精神,实现信息的高效流通。总体而言,从社会资本视角来说,要想获取能力要素,就要在实践中建立一种共同的认知模式,不断提升团队中所有员工从网络节点中获取知识的能力。

(三)从参与机会要素角度分析

工作结构设计是参与机会要素的着眼点,实际上就是赋予团队中每一位员工处理信息的权力,而不是将收集信息和处理信息的机会或者说权力都留给管理者。在传统人力资源原理中,在设计工作任务时往往会将重点放在任务结构上,但是实际上,没有任何一项工作任务是独立存在的,或是要与团队人员发生关系,或是要与顾客之间发生关系,也就是说任何一个任务的完成都离不开互动。因此在设计工作结构时,需要将员工关系考虑在内,明确各个职位之间的依赖性,从社会关系网络的视角来制定工作任务,形成一个完整的任务网络。任务并不是一成不变的,可能会在各个部门或者是各个员工之间流动,而且团队管理者有义务为员工完成任务创造一个互动平台。总的来说,机会参与要素就是注重职位与任务之间的关联性,促进员工与社会关系网络之间的交流,实现人人参与、提升互动的有效性。

三、研发团队人力资源管理实践的价值分析

(一)动机要素在社会资本情感维度的价值

社会关系网络中人际互动质量在很大程度上都取决于动机要素,我们可以将研发团队内部员工之间的关系理解为市场上的一种交易关系,交换信息与资源的过程实际是员工之间互利互惠的过程,对于社会资本来说,动机要素主要在情感维度发挥价值。针对研发团队的人力资源管理实践过程实际上能够反映出员工之间的关系,并为改善这种关系提供引导,使员工之间在无形中建立一种信任规则,或是形成一种具有即时性回报的交换关系,或是形成一种具备长期性的交换关系。要求企业研发团队管理人员从长远发展考虑问题,开展一些具备完善性动机的人力资源管理实践,强调团队的共同目标,建立员工对研发团队或者说对社会关系网络的广泛信任。可以建立集体奖励制度,也可以计划集体利益分享方案,还可以设置员工持股计划,提升员工的集体责任感,在工作中关注集体利益多于个人利益,这样员工才能自愿分享自己掌握的信息,实现网络节点之间信息的有效流通,真正做到资源共享。

(二)能力要素在社会资本认知维度的价值

研发团队进行人力资源管理实践的过程实际上就是建立团队内部统一认知模式的过程。不仅要求员工提升个体能力,同时要求员工能够协调好自身与社会网络之间的关系,对社会资本的认知维度产生积极影响。也就是说,对于社会资本来说,能力要素主要在认知维度发挥价值,具体体现在以下两方面:一是要建立一种共同的认知模式,研发团队中的人才大多数都是知识型人才,团队在招募员工的过程中,一方面要考察其掌握的知识是否与团队的知识体系相符合,另一方面还要考察其价值观是否与团队一致,只有这两点都符合要求,员工才能迅速融入到团队中,与原有的老员工形成统一的认知模式,为团队中各个网络节点之间的交流打下良好基础;二是要求员工有能力协调好团队内部开展的各项活动,员工在进入团队以后,要努力获取更多技能,在脑海中形成一种结构化的知识。培训就是提高员工这种能力的重要途径,一方面员工的知识与能力在培训过程中增长;另一方面可以在团队内部形成一种结构化的知识体系。对团队整体进行培训,不仅能够有效促进员工之间的交流,员工在交流的过程中还能相互了解彼此掌握的知识与技能,不断提升员工对网络节点知识的吸收能力。

(三)参与机会在社会资本情感维度的价值

研发团队中的所有员工需要与管理者获取均等的参与机会,这种参与体现在信息收集上,也体现在信息处理上,只有员工真正获取参与机会,才能在网络节点中获取知识和资源,团队工作结构的设计才能更加合理,也就是对于社会资本来说,参与机会主要在结构维度发挥价值。研发团队在设计工作结构时,需要明确每个员工的具体工作内容、任务的独立性以及关联性等,并将这些信息作为基础为员工提供交流机会,促进任务在员工之间的流动,提升完成任务的效率。而企业与研发团队之间的关系绝不是简单的管理与被管理的关系,企业需要为整个团队创造一种与任务相匹配器的工作环境,员工与员工之间不是简单的整合,而是要将员工“嵌入”到整个团队中,实现信息的横向共享,促进员工之间的交流与互利互惠。尤其是对于那些知识跨度比较大的项目,需要在团队内部成立一个临时小组,由掌握不同知识结构的人员构成,为不同领域的知识交流服务。除此之外,研发团队可以实行职位轮换机制,为不同岗位的员工提供更广泛的交流机会。

四、总结

当前全球已经进入了知识经济时代,企业在发展中对于研发团队的依赖程度越来越强,而研发团队发挥价值的基础是社会关系网络,企业在开展人力资源管理实践的过程中要将社会关系网络作为基础,明确员工以及工作任务之间的关联性,不断提升研发团队的产出绩效。

参考文献

[1]林亚清,赵曙明.构建高层管理团队社会网络的人力资源实践、战略柔性与企业绩效——环境不确定性的调节作用[J].南开管理评论,2013,12(14).

[2]黄爱华,李敏.基于社会网络的HRM与一线管理者之间的信息沟通[J].科技管理研究,2010,13(14).

篇5:研发部技术服务团队建设管理办法

一、氛围营造

技术服务人员是市场一线人员,团队大学生多、年轻人多,又是几个月回差一次,单独工作时间长,回归聚拢时间短,情绪波动比较大,薪酬不稳定,跳槽频繁,所以都要求管理充分发挥缓冲作用。总之,要营造一种氛围,使大家有一个倾诉委屈不满、调整心态、协调与各部门关系的空间。

技术人员回公司后主要以会议形式进行一线经验交流分享为主,同时给予充分自由活动的空间与时间,如逛街购物、处理个人问题、小范围交流、休息等。

二、职业规划(此团队从业人员晋升方向)

技术员→主任→经理(垂直升迁);

技术员→业务→升为业务经理(干得好的话);技术员→化验、研发、企划宣传、内部管理(转岗);

技术员→个人直营店(公司提供扶持政策);

如果员工还没有给自己定位,就要让他明白,积累不同的经验和知识结构,也是在为自己提升个人价值含金量,可以帮他们定一个1-3年的短期目标,引导他们在有限的时段内,主观上学到东西(良好的心理素质、有效的沟通口才、自然地敬业习惯、相当的动脑动手能力等),客观上干好本职工作。

三、薪酬设计

技术服务人员薪酬主要由两方面组成:

1.基本工资:按业内现行的薪酬结构来分析,技术员基本工资多在1500-2000之间,实习期1500,转正后2000。

2.技术服务提成:按所服务地区销售额的3%提点。

四、制度管理

任务分解备案制——片区经理或销售经理填写技术员当月市场任务分解表并交人事部存档。

派出登记制——人事部根据片区任务分解表,登记技术人员的市场去向并管理出差签离和回归签到,会同请销假作为考勤依据。库存盘点制——技术员每月要盘点所在门市的产品库存,包括数量、品种和保质期等,使企业和个人都明了产品的市场状况,最好还要有业务员、经销商的签字。

电话查岗制——部门要不定期以电话的形式与技术员保持沟通联系,技术员要按规定时间以当地电话向研发部汇报当地市场情况。销量审核制——技术员的门市销量要经研发部、销售部、财务部门三级部门审核。

投稿奖励制——技术员的技术稿件被各级专业媒体发表的,给予一定的奖励。

工作汇报制——技术员要按规定向部门经理汇报述职,包括当月典型病例、门市经营状况、库存盘点、病例笔记手册等。

培训考试制——每年一次培训并佐以考试,对考试成绩张榜公布,脱考和不及格的要进行补考。

辞职和请销假制——要提前一个月提出辞职申请,公司安排替岗人员方可离职,并与工资发放挂钩,不准擅自脱岗。

入职、调职、离职谈话制——尤其是技术员离职,要征询其对企业管理的意见和建议,指出企业和员工双方的优缺点,解释误会等。对调动片区的要了解缘由,是因在原片区不适应不协调,还是自己想换环境,还是为扬长避短发挥强项等。

需要注意的是,制度不是冷硬的框框,在执行中要保持一定的伸缩弹性,操作点是人治与法制的适度平衡,对可能影响团队凝聚力的违规不能让步,如对违规离职的处罚,派出登记制度、培训考试制度、销量审核制度等。

另一方面是充分发挥片区经理人的作用,技术团队组建之初、人数较多或片区管理尚不成熟时,应以部门管理为主,强化团队向心力,不要急于削弱部门职能;当技术队伍相对稳定、片区管理比较成熟时,就应向部门管理与片区化管理相结合来过渡,一段时间后,就可以片区化管理为主了,这时,部门任务可以分解给片区,部门职能可以相对弱化,工作内容也可以转为主抓技术培训。

篇6:研发团队口号标语

42、尖端雄才平台,造就科技王国。

43、依托先进的平台,雄厚的团队,让技术一路。

44、好钢用于刃,开发高尖精。

45、技术推动进步,研发成就未来。

46、生命在于运动,科技在于创新。

47、科技成就未来,产业振兴生命。

48、科技导引现代研发,研发最终精进科技。

49、要想科技发,建议靠大家。

50、世界已变,科技出现,生产虽慢,产中精品。

51、科技需要展示的舞台,更需要精锐的后台。

52、如果当初没有流水线,可能除了农业以外就不存在量产。

53、集研发团队,助科技创新。

54、创新是企业的灵魂,经济发展的必然结果。

55、研发创新技术推动变革。

56、团结拼搏,打造人才,进军新业。

57、研发——科技发展之源泉。

58、用科技生产力来证明一切。

59、科研发展,自立自强。

上一篇:九年级抉择作文800字下一篇:户口迁移证明怎么写