企业研发需要什么样的人？

不争朝夕zm 2020-02-23

展开全文

没人，什么都白扯！

人不对，还不如白扯！

但凡负责过业务的领导，都知道人才的重要性。可如何招到合适的人，如何判断已有的人是否合格、适用，是现实的挑战。我们今天聊聊企业的研发都需要什么样的人。

首先澄清几个概念：

1，研发也是职业，一个员工如果不是普通意义上的好员工就不可能是好的研发人才。所以研发人才的要求可以特殊，但不可以例外。如果一个企业的文化出现偏差，连对好员工的定义都出现了偏差，那就不用扯研发这事儿了，皮之不存，毛将焉附！

2，企业的研发跟普遍意义上的高校类研究不是一回事儿，高校类学术研究是为了回答一个疑问，目的是产生知识。企业是要创造经济价值的，所以企业的研发是用知识，结合队伍的能力，解决现实的问题（problem, 不是question），产生能用的方案/产品并销售，获得收益。因此，企业对研发相关人员的要求要比高校类研究复杂的多。

关于怎么招到和培养有发展潜力的好员工，我以后另文再讲，大家有兴趣可以先自己寻找各个成功的大企业关于员工价值观的判断标准。比如通用电气公司的Clear Thinking(逻辑清晰)，Imagination(头脑灵活)，Inclusive(有包容性)，External Focus（不自以为是，客户/客观为主），Expertise(专业技能)。当然还得加一条，做事有激情（Passion）。一个人做事要是没动力，再牛掰的能力也是白扯！在组织里担的责任越大，对这几条的要求就越高。

在这些通用的好员工选拔标准之上，这里重点分析一下研发队伍的不同角色和对他们的核心能力要求。上面讲到，企业研发是用知识去解决问题，所以我们从知识和问题这两个维度来分析。把这两个方面联系起来形成有机整体的核心能力是逻辑思考能力，我们单独提炼出来讨论。

表1：不同等级研发岗位对应的知识储备要求、所能解决的问题和逻辑能力要求。

表1 列出了不同的知识能力等级的人在体系中所能承担的角色。这里需要指出的是，每一级都是上一级能力的基础，如果下面各级的能力和经验基础不牢，贸然跳到更高级别的岗位，就会出现“工作依赖嘴皮子、形象工程满院子、团队扯皮转圈子、实际效果花架子”的后果。

从另一个方向看，也不能只强调经验和本层级的胜任能力，每一层级还要能准确理解上面一层的考虑维度和对自己及以下各层的影响，形成良性互动，才能不至于盲从和蛮干。

再者，即使是每个角色能力能够胜任职责，也并不代表就足够了，因为企业之间的本质是竞争提高效率，要在各个层级做的比同行更好才能为所在的公司换来竞争优势和生存价值。

下面我们逐级解释一下各个层级面对的问题（职责）和对他们知识/能力的要求：

1，最底层承担辅助性工作的员工：能准确理解指令并依据基本的技能和工具，转化为具体的行动，生成满足要求的结果（比如：实验员，技工，文秘等等）。

2，有专业化分工的职务：这里主要指对一个具体的工种或具体事情负责，比如财务负责报销的专员、负责化学品管理的专员、负责入职流程的专员、负责社保的专员、负责生产过程的班长、负责实验装置的专员等等。对他们的要求是熟悉相关的规定和流程要求，具体的操作方式方法，了解各种要求背后的原因和判断尺度，在具体的合规性事务上把关和判断。能对照标准（广义）识别问题并给出行动建议，这些行动建议应该是已有的或经过验证可行的方案。他们需要具备判断确定性的问题与确定性的原因和确定性的答案之间的逻辑关系的能力（如图1 (a)）。

3，工程师：作为一个能独立工作的技术人员，工程师应该对与工作相关的、自己专业领域内的已有知识全盘掌握，或者知道怎么去查找。对于一个没有研发/创新业务的组织，工程师可能就是这个单位里最资深的技术力量了。当产品或者工艺出现简单问题的时候，应当能对问题的重要性、影响和背后产生的原因做出合理推断，根据行业知识找出合适的解决方案。每一个技术人员只要努力学习和给予合适的技术培训都应当能做到这一点。博士毕业一两年，或者经过六西格玛绿带认证的员工基本上处于这个水平。这个级别工程师的典型特征是：当问题交代清楚后，对于解决问题的流程和思路有清晰的了解，可以不需要帮助和指导，能独立地去通过探索问题背后的原因，基于已有的知识体系，解决简单的技术问题。具备基本的“问题-影响因素-解决方案”的思维逻辑套路。核心逻辑能力是找到确定性的问题与不确定的影响因素和已知的知识之间的关系（如图1 (b)）。

4，独立研发项目承担人：这里大多是一个边界相对清晰的研发项目的项目经理（或技术骨干），或者是一个大型项目中相对独立的任务，需要几个人分工协作完成。首先，这个独立的研发任务的目标（所要解决的问题）往往需要承担人与客户（或更大系统的负责人）协商确定，知道如何正确科学地定义一个问题。其次，对问题进行科学地拆解，使一个复杂的问题可以拆解成多个能找到明确影响因素的子问题，然后再把这一系列的子问题交给不同的团队成员解决，每个子问题的解决方案通过整合优化，最终成为项目的解决方案。所以独立研发项目承担人的核心逻辑能力是准确地理解和管理带有不确定性的问题之间关系，即问题与问题之间的关系。换句话说，准确理解和分析未知与未知之间关系的能力（如图1 (c)）。这已经超出日常生活中的大多数人的领悟能力了。

图1：职级与解决问题能力的关系

一个从大问题中拆解出来的二级子问题很可能还需要进一步拆解到下一层的三级子问题，甚至更多层问题拆解，到四层、五层等等（如图2）。需要拆解的层级越多，对负责人的问题拆解能力和技巧的要求越高，这种能领悟多维度问题累进逻辑关系的人才也越稀少，往往需要特殊的逻辑训练和多年的练习。技术大咖往往能把一个宏观的大问题迅速分解成多层次的问题体系，并找出问题分解树里面的薄弱环节或风险点。

现实生活中为什么合格的技术大咖很少？有以下几个挑战：

1，具备这种能敏锐的理解未知与未知之间逻辑关系且能与其他逻辑关系区分开的好苗子很少。就像我们普通人能很容易理解收益的量化，也能理解定性的风险与量化的收益。但是能下意思地对风险形成量化的感觉就凤毛麟角了，如果能把不同的风险形成量化意识、再形成不同风险之间的量化关系从而指导自己的决策和思维，就更是可遇不可求了，更遑论风险（未知）的多级分层量化了。

2，对于风险和不确定性有一套工具和方法论来梳理和量化，很多人不了解这些工具的存在，更多的人对研发能力缺乏一个正确的理解，往往也意识不到这些风险/问题的分析量化工具的作用和重要性。

3，另一个挑战是互相的误解：没有这种思维能力的人不知道自己不知道什么，无从练起。具有这种思维能力的人以为大家天然就有，不理解为什么别人不会这么思考，更不会想到这是一种能力，可以通过培训把不懂的人提高。只有极少数的人意识到这是一种技能，对于有潜力的人是可学可教的，才会想到要对不具备的人进行培训。

4，大多数人不知道如何识别哪些人有可学可教的潜力，尤其是因为有技术专长而坐上领导岗位的人，很多对于“人”是一窍不通的。

如果要选拔好苗子进行培养，怎么才能在职业早期识别出有潜质的员工呢？另一方面，如果从外面招，怎么知道面试的人是有真材实料还是貌似经验很多其实只是花架子、耍耍嘴皮子？

这群人的成就大小、能力高低都决于两个基本素质：1，高度敏感/严密的逻辑推理能力；2，对“为什么”打破砂锅问到底的钻研劲头。这两个素质只要缺一个，在这条路上一定走不远。这两条素质的过硬程度决定了他们发展潜力所能达到的高度。至于其他的软技能和工作技巧，只要有合适的“师傅”带领，有完善的培训体系，都可以在工作中历练得到，只有这两条是一个人的本性，难以随时间改变。

一个研发组织能取得多大的成就，这个群体的素质和能力的成长是基础。否则，巧妇难为无米之炊，再好的体制、战略、计划和投入都是打水漂。选不对合适的人，一切都是白扯，甚至，比白扯还糟糕。

大多数组织的技术职称分级或者说技术职业发展路径都基于这一逻辑。

图2：解决复杂问题能力

5，学术带头人：经过多年多个研发项目的开发历练，一部分善思考、勤学习、好钻研、思路广的项目负责人就慢慢的走到了某个技术领域的最前沿。这个群体掌握着某个技术领域里最前沿的信息，不一定是科学意义上的学术大牛，但经过多年的研发和经验积累，应该对某个应用技术领域的研究现状和整个行业的技术边界有清晰的认识，对于一个技术和该技术对应的业务领域的问题在过去多年的演变过程有清晰的了解。如果只是在一个领域干的年头多，经验丰富知道东西的多，并不见得能胜任学术带头人的责任，但是对前沿和行业技术动态的了解是基础。有了最前沿的信息，合格的学术带头人应该能基于行业需求的发展过程，结合技术领域里自己团队和竞争对手的研究团队的研发活动，预测行业的大致发展路径，同时预测潜在的技术突破机会，带领团队做到提前布局，并能够评估成功的几率，从而评估研发活动的投资回报率以及对公司业务的促进作用。做到这一点，几乎就是一个具体技术领域里的最高水平了。换句话说，合格学术带头人的核心能力是能正确地定义未来的研发问题，帮助公司在业务上提前布局，获得超前竞争优势。

6，研发管理负责人：研发管理的核心决策是通盘考虑公司的研发资源（资金、设备、团队能力、业务发展趋势和市场竞争态势）在众多的项目计划中筛选出高性价比的研发项目给与立项，并对根据每个项目的进展和新的信息随时对项目组合做出调整，最大化公司的在研发创新领域的投资回报率。要根据行业周期和公司的定位，形成合理的短期、中期、长期项目组合。即有利于公司短期盈利，又能获得长期的业务优势。

如果要胜任这个角色，必须深度理解不同类项项目的核心风险，对项目技术风险的把控和所要解决的业务问题的价值理解要非常精准，同时还要对各个行业的运行规律和自己公司的业务模式/产业定位有深刻的理解。这几条只要有一条的把控出现偏差，就会形成错误的项目投资组合，甚至出现项目开发很成功但业务很失败的情况。

核心逻辑能力：对每一种风险（市场、业务、技术、团队）背后的贡献因素以及各个因素之间的量化逻辑有全面和精准的了解。

很多公司并没有一个专职的岗位来做研发项目的投资决策和过程管理。如果公司业务足够单一，有可能这个角色由学术带头人顺带完成。如果公司的研发部门不大，研发组织的负责人便有可能同时兼任投资决策的角色。更小的公司，也会发生学术带头人、研发投资决策和研发组织负责人三个角色一身兼。但不管如何在组织上分配这三个角色，它们背后的核心要素和逻辑是不一样的。

鉴于研发投资组合决策的重要性，我们以后另文专门论述研发项目的组合策略和技巧，以及研发项目本身质量的判断方法。

7，研发组织负责人：研发组织是一个运行整体，一切研发活动都是依托一个研发组织来完成，一个完善的研发组织应该覆盖研发活动所需要的所有职能。任何一个组织搭建和运行的核心三要素：责、权、利。对于研发组织的负责人来说，他的核心挑战是如何基于研发活动的特质，搭建合理的组织架构（分责）、设计合理的管理流程（分权）以及高效的奖惩机制（分利）。比如说组织架构，除了前面提到的技术/项目类角色1-6，团队怎么分？人员怎么管？部门经理与项目经理怎么合作？安全/财务/人事/后勤怎么设，与项目团队怎么互动？如果对研发活动的本质没有深刻的理解，照搬其他组织的架构和流程，就会处处掣肘、事事不顺、互相埋怨。即便是把世界上最牛的人放到一起，也只会是乌合之众乌烟罡气。

当合理的组织架构和流程到位之后，组织负责人的重要能力就是是否能把合适的人放到合适的岗位上去。如上面所述，每个岗位有对应的“硬技能要求”，也有“软实力的倾向”，比如把一个性格内向的人安排到一个要每天跟无数人打交道的服务岗位一定是个灾难，不管这个人的知识和能力上多么胜任。反过来讲，把一个喜欢跟人打交道的人安排去处理大量枯燥的数据，出错几乎是在所难免的。组织负责人需要对每个工作岗位的性质有充分的了解并对人性有相当的洞见。

关于如何为一个研发组织“分责、分权”，以后在“研发组织的管理”的文章中再详细介绍。关于如何“分利”，在“研发队伍的培养和管理”部分再探讨。

以项目中的研发任务外包为例。这本质上是一个服务，外面有团队具备合适的能力，项目需要这种研发能力作为一种服务，获得项目需要的结果（样机设计、零件开发、机理探索、性能评估测试、子系统的开发等等），所以从采购定性的角度，这是一个服务采购，一个研发服务的采购。某公司规定，所有的采购（包括服务采购）到达一定数额，都需要走公开招标流程，因此，“我方”付钱的对外技术合作也必须走公开招标。于是有意思的事情发生了，所有技术/研发出身的人觉得不可思议，怎么会有这么奇葩的要求？别的公司对自己的研发项目保密还来不及，我们却要公开招标？既然是招标，所有的结果都是未知的，这招标文件怎么写？感觉肯定有问题，但是大家却说不清哪里不对。对于非研发背景的同事来说，既然这是一个采购，我花钱买服务，怎么别的服务能招标，偏偏你们研发的服务就不能招标呢？

这是因为研发与所有其他业务的一个核心区别被忽略了。如图3所示，研发的核心职能是从一个未知（问题）出发，通过研发活动获得一个已知（方案），而其他一般业务活动都是基于一个确定的已知，通过各种业务运作获得收益。对于一个确定的出发点，过程也是明确的，所以招标的方式实施起来没有技术挑战，完全符合招标这种方式本来的出发点：确定、透明、可懂、可比。但对于一个研发任务，它的出发点是一个未知，目的就是获得一个确定性（已知），那么以一个未知作为出发点，招标的核心逻辑就完全不存在了。

图3：研发活动与业务活动的内在本质区别和联系

一个研发负责人如果不能对这些研发的底层逻辑和特点有深刻的认识，就会对内难以设计出合理适用的组织和流程，影响研发效率；对外代表研发组织与企业里的其他部门配合的过程中，无法达成有效的沟通，容易生成很多误解，难以形成有效互动、成为一个有机的整体，最终无法为公司创造效益，形成浪费。

对外，研发组织作为整个公司的一部分，研发组织的负责人需要确定自己的研发组织在整个产业链/研发链中的定位，即：以什么角度帮业务集团解决什么类型的问题。一个组织不可能是万能的，也不可能资源无穷多，必须在所有的技术相关问题上有所取舍，确定组织的工作重点并围绕工作重点打造相应的软件、硬件和人员能力。

在确定了定位的基础上，研发组织负责人还要牵头与所关联的业务部门协调，一起建立流畅有效的工作配合机制（有效，可持续）。这里需要强调，依靠个人关系建立的联系是个好的开端和铺垫，需要进一步发展成为不以人的意志为转移的自我运行的一整套运行管理机制，把个人关系转化为组织关系。否则就会出现人走茶凉，工作难以持续的且不稳定。

图4：研发组织负责人的能力模型

组织的负责人还必须是“人精儿”！这个社会毕竟是“人”的社会，如何管理好一个由人构成的组织，对人的认识必须深刻精准。

首先，负责人必须对人性有深刻的理解，工作安排如果符合人性，就很容易开展，如果违背人性就会寸步难行。当一个组织的职责和流程设定，或者工作安排出现问题的时候，组织负责人要能迅速地识别出是否由人性的因素造成，如果有，则必须首先解决和改变。

其次，负责人必须对自己组织里每个角色的能力模型有准确的认知，这样在安排人员时才能判断一个人是否具备胜任这个角色的能力，潜在的弱项是什么。对组织的弱点能有准确的判断和预估，在发展组织时，知道从哪些角度出发能做到事半功倍。

8，企业科技创新的主管领导：科技创新的主管领导是把科技体系与整个企业的运营融为一体的人。如果一个企业不大，业务相对单一，那么企业的总经理就是科技创新的主管领导，如果企业业务构成复杂且体量庞大，那么就有可能有一个专职的主管领导。

主管领导必须能深刻理解科技创新是企业的一个功能，不是一个独立存在的业务。科研部门负责探索，厘清风险，提供方案和选项，然后由业务部门依据科研队伍的结果，结合业务上的非技术因素一起，制定投资和业务计划，从而实现企业效益的提升。在这里必须强调，科技创新是为业务服务的，是替业务解决当前问题或探索未来道路的，但路是要业务部门自己去走，而企业的效益也必须由业务活动来实现。

业务部门作为这个链条上的甲方，必须负责为乙方（研发部门）提供产业发展方向的指示，如果业务部门在这方面没有合格的知识储备和战略思考，就必然会出现乱指方向，或不作为要求研发部门自己定方向的现象。造成的后果就是研发部门出了一堆成果业务部门没法落地。所以，如何把业务部门打造成研发创新链条上合格的甲方是主管领导的重要职责。如果一个科技创新的主管领导认为自己就是要把科研队伍管好，那就是把自己降格为研发组织的负责人了。所以当一个企业的领导追问研发部门的直接经济效益的时候，那么整个公司的创新体系，尤其是业务部门的创新职能一定出现了问题！

业务部门是研发部门的生存基础，是天和地，如果天地在创新这件事儿上失职，研发部门是无力解决的，这就是考验科技创新主管领导睿智的时候了。

因此，作为企业创新体系的负责人，如何提高企业（注意，不是研发部门）的创新效率，创造更多的经济价值是核心责任。需要在工作中紧紧抓住业务部门这个创新链条的龙头。如果业务部门在创新战略的实施上有任何闪失，造成的后果都是不可弥补的。

那么，作为创新体系的负责人，在主抓业务部门创新职能时需要注意什么？

1，深刻理解业务部门在创新体系中的头尾作用。业务部门才是创新需求的提出者，任何没有业务部门认可的创新活动都是无源之水，无本之木。所有的创新成果要由业务部门（全套商业功能）来实施，如果一个成果没有一个对应的业务部门，必然无法对本企业创造价值（技术转让/许可也是通过广义上的“业务部门”—技术受让方—产生效益）。

2，对业务部门实施正确的考核和激励手段，促使他们发挥创新龙头和龙尾的作用。作为龙头，要考核他们是否有高效的需求收集和筛选机制，提出的研发目标是否契合业务发展战略，是否了解市场和竞争对手的前瞻布局，是否有效利用企业内外的创新力量。作为龙尾，要考核业务部门是否有成熟稳定的研发成果评估和接收机制，是否了解新技术新产品的生产推广规律，相应的队伍是否完善。

创新体系管理常见的误区：

1，认为创新是研发部门的事儿，导致业务部门在创新链条上缺位，整个体系无法发挥作用，体系运作难以持续。

2，考核指标错位。比如把业务部门当成创新活动的主体，用考核研发部门的指标考核业务部门。比如考核业务部门的知识产权数量（专利数），导致业务部门与研发队伍在本是一家人的情况下争抢知识产权的冠名或名义归属（实际都是归属整个企业）。或者用直接的经济指标考核研发部门，导致研发部门热衷于自立门户，进入生产销售，对服务本企业的业务部门不积极不热心，甚至把业务部门当成竞争对手。

3，不能结合本企业所在的行业特点，盲目地与别的行业的企业攀比对标。一个企业所在行业的发展曲线一般符合图5所示的S曲线，在不同的发展阶段，技术演进的特点和作用不同，企业需要采取不同的风险和投资评估机制，技术发展的曲线会略早于行业曲线。在早期，技术/行业前景高度不确定，需要多点布局，小心试探，积极求证，避免冒进。中期，行业/技术爆发，行动慢是最大的风险。后期，技术/行业走向成熟，需求和回报相对明确，是企业运行的基础，但难以形成高回报的投资机会，决策避免掉入舒适区陷阱，固步自封，忽视新技术/业务模式的产生。