技术研发中心的组织结构

技术研发中心的组织结构

随着国际及国内技术竞争的加剧，企业或组织的兴亡成败越来越多地与技术的强弱有了紧密联系。在很多行业，无论是技工贸一体化的企业，还是纯技术型企业，都不可避免地涉及一个问题：以什么样的结构来组织技术研发中心，能够取得最好的效果。

在技工贸一体化的企业中，营销中心及生产运营中心的组织结构，往往已经有了主流的公认答案。随便找一个职场人士，问他（她）生产运营中心的常见组织结构，多半会给出正确的回答：生产部、采购部、品质部、储运部（物流部）。

但是，对于技术中心的组织结构，能够答得上来的职场人士却很少。在本文中，笔者试图对此作一些探讨。但是由于技术领域的广泛性，以及行业的广泛性，本文不可避免地具有局限性。希望能够起到抛砖引玉的作用。

根据笔者的调查，目前可能的技术中心组织结构主要有四种：按照项目来分工；按照子系统来分工；按照技术领域来分工；按照职能来分工。

1.按照项目来分工，往往有三种情况：

1.1.单一技术领域，例如软件行业（尽管还可以细分子领域）。在一些规模不是

很大的软件公司里，由软件高工担任项目经理，往往能够取得不错的效果。

当然，软件高工有两种，一种是架构师，另一种是高级算法师；架构师有全局观，担任项目经理比较容易管好；而高级算法师更适合作为公司的核心资源在各个项目之间调剂；除非是某些以算法为主的项目，由高级算法师主持更合适。单一技术领域的行业还有很多，采用按项目划分的方式往往能取得不错的效果。

1.2.一个技术领域要求较高，其它还有一至数个辅助技术领域。例如，开发电源

电子产品，在电子方面的技术较深，而产品结构框架及外壳比较简单，内部的单片机嵌入软件规模较小。这种情况下，由电子高工担任项目经理，领导机械结构工程师及嵌入软件工程师，是个可行的安排，项目成功率较高。

1.3.两个或两个以上的技术领域要求较高。这时候往往会遇到一个问题，项目经

理可能在一个领域水平较高，但是在别的领域较弱。例如，在某通讯公司，某软件高工担任项目经理，主持开发嵌入复杂软件的复杂芯片。他把软件架构做得很好，但是由于他在微电子方面比较弱，所以微电子架构存在很多问题，后来问题不断冒出来，进度屡屡延误。在此期间，他也曾向担任其他项目经理的几位微电子高工求助，但是由于项目经理之间是竞争关系，所以得到的答复总是“对不起，没有时间”。

2.按照子系统来分工

《中国人民解放军武器装备研制设计师系统及行政指挥系统工作条例》规定：大型武器系统的研制由一位总设计师和一位总指挥联席主持工作。总设计师下设多位子系统主任设计师，每位主任设计师下设多位模块主管设计师，主管设计师下设多位设计员。同时，总指挥下设各级指挥员。

这种组织结构主要有两个特点：一是对专业官与行政官的角色进行了清晰的区分；二是按照自顶向下的系统分层结构来部署组织结构。

在系统高度复杂的情况下，这种安排很可能是唯一的选择。但是，这种安排有一个缺点，就是组织结构与产品结构严格挂钩。当需要进行架构创新时，可能取消某个子系统，扩大某个子系统，精简某个子系统。这就必然会导致组织结构之间此消彼长，但是哪个负责人愿意看到自己的地盘减小甚至消失？因此政治阻力在所难免，技术问题与政治问题就会相互纠缠。好在军方项目把子系统及模块分配给各个承接单位，这种此消彼长只是跨单位之间的利益关系，相对容易协调。但是，如果一个企业内部的技术研发中心拟采用这种组织结构，就要慎重了！

3.按照技术领域来分工

优点在于：

A.各部门之间的利益界面比较简单，容易协调。虽然一定程度上也有踢皮球或

抢地盘的问题，例如某些控制功能，既可以用机械方法来实现，也可以用电

路来实现，还可以用软件算法来实现；但是，这都不会导致哪个技术领域被全部取消，只要技术总监出面协调，就能够得到较好的解决。

B.各领域技术人员的技术水平，决定了其自身的升、降、辞，从而激发了技术

人员精益求精，不断钻研的动力，有利于打造企业的核心竞争力。

C.各个不同项目在同一个技术领域的任务会由同一个部门完成，容易积累经验

及教训。既可以避免在不同的项目上犯相同的错误，又可以把一个项目上取得的创新移植到其它项目上。

D.便于实施专业审核与逐级杀头制。在前述按照项目分工的的情况下，项目经

理可能是一个领域的高工，但下属中有其它领域的工程师；也可能会由纯管理人员（例如没有技术背景的MBA）担任项目经理。在这两种情况下，项目经理很可能在审核工程师编制的技术文件时，闭着眼睛签字；事后出了问题，就推托说，自己不是这个专业的，主要问题是公司给自己配备的工程师太差，而把好的工程师都配给其他项目经理了。在按照技术领域分工的情况下，机械高工（机械经理）如果没有审出机械工程师的模具图有问题，而导致模具报废损失惨重的话，理所当然要卷铺盖走人。

缺点在于：

A.各个技术部门及各领域技术人员对项目的成败不够重视，只要老板对自己的

水平满意就可以了。我们有的老兄甚至以各个项目合用人力资源为借口，推脱工作量，人为制造项目之间的矛盾冲突。

B.在这种组织结构下，增加一个项目不需要增加一个项目团队，不会导致直接

可见的人力资源成本，所以有些好大喜功的老板往往会在无意中不断立项，项目越来越多。同时老板又不太愿意给各个部门增员，从而导致资源冲突，每个项目都进展缓慢。

上述两个缺点听起来很像微观经济学的信息不对称博弈。

4.按照职能来分工

这听起来似乎有点像生产运营中心了，那是最典型的按照职能来分工的。

其实，技术研发中心的职能，也是可以好好地分工一下的：

4.1.研发质量部

产品的研发过程，是产品质量的源头。虽然在生产运营中心也有质量部，但是要让运营质量部兼顾研发质量，往往比较困难。原因在于：

A.传统的运营质量部熟悉的是ISO9000或类似的质量体系，这类质量体系

在研发质量管理方面非常薄弱。

B.传统的运营质量部擅长统计分析，这类方法在研发质量管理方面用武之

地较少。

C.传统的运营质量部擅长按照已经编好的标准来检验产品，却不善于编制

标准。也就是说，擅长执法而不擅长立法。当然，从另一个角度来看，

要求执法者去立法，也不是很合理。

D.有些大公司，研发中心与运营中心隔得比较远，甚至可能不在同一个国

家。

设立专业的研发质量部，有下述优点：

E.传统上，标准的编制，根据其重要性，往往由各个层级的技术人员来完

成。这往往会导致自己设计自己立法的情况，缺乏公信力。而由专业的

研发质量部来立法，比较合理。

F.配置版本管理，对于技术研发工作具有较高的重要性。但是其工作量又

不是很大，难度也不是很高。在规模不大的研发中心，没有必要成立专

门的配置管理部。由于配置管理是研发质量管理的重要支柱，由研发质

量部经理来统筹这项工作，下面设立一个配置主管的岗位，是较好的安

排。

G.有利于更好地推行专业的研发质量管理体系，例如CMMI等。