前言
本文主要是针对那些准备建设研发组织的领导、或者新研发组织里的各层管理者、或者没有真正在竞争性的成熟研发组织里历练过但又很需要相关知识的人员。
对于竞争性行业里稳定运行的研发组织的管理者，本文的内容可能属于非常基本的常识，基本到甚至感觉不到这些逻辑的存在，但又每天工作在其中。
国内市场上，体制内的研发组织，很多运行起来问题多多，很大一部分原因是这些最基本的管理逻辑的缺失，处在其中的人要么是认识不到，要么是周围有太多不明白的人而无力回天。
摘要
1. 研发组织是企业的组成部分，必须以企业的效益提升为目的。
2. 研发活动是手段，不是目的。所有的研发活动必须以解决企业的技术需求为目的。
3. 企业的中短期技术需求必须由产业部门负责制定，长期发展需求由总部战略责任部门制定，别的部门或研发组织可以辅助或提议，但产业部门不能免责。
4. 责权利统一，谁的需求谁负责出资开展研发活动，出资必须是全口径覆盖。直接经费和间接经费的分口管理模式危害巨大。
5. 企业必须有成体系的科研成果管理机制，最大化整体利益。
以上各条，企业的技术主管领导必须有深刻的认识并负责亲自落实。
1. 研发组织必须建立与产业部门的需求对接机制（定时、定点、定人、定交付物）。
2. 项目的确定必须根据不同类型的需求落实投资回报率评估。
3. 研发组织内部需要有完善的项目评估和立项机制。
4. 项目在执行过程，目的是为产业提供投资决策，需要时时评估继续执行的必要性，以最优的路径、最少的支出获得可靠的结论。
5. 管项目与管组织是两个截然不同的逻辑，要杜绝以管组织的方式管项目，甚至于用管组织来代替管项目，造成因人设事的恶果。
以上各条，研发组织负责人必须有深刻的认识并负责落实。
图片
企业是要盈利的，企业里所有的部门都是围绕这个最终目的在运作。围绕这个目的的责、权、利是企业里所有管理的核心。所谓管理体系，就是围绕责、权、利的制度设计和运行管理。权责不清或权责不一致，是各种管理问题的病根儿，研发组织也不例外。
行事前，列梗概；
责权利，是利害；
有责无权是陷害，
有责无利受伤害；
有利无责是溺爱，
有权无责生腐败。
责权不清把事害，
心焦力疲互相怪；
领责行权利放开，
功成利现皆开怀。
所谓研发管理体系，就是围绕研发组织这个主体，在两个层面的责权利体系设计。
一是确定研发组织作为整体，与企业的其他部分之间的责权利的体系设计，我们称之为大研发体系；
二是在研发组织内部的责权利管理体系设计，我们称之为小研发体系。
我们就以研发部门的视角，依托外责、权、利和内责、权、利这六个方面来介绍大研发体系和小研发体系应该如何搭建。
第一部分：大研发体系
研发组织作为企业内部的一部分，其运作和功能也必须与整个企业的运行融合贯通。研发组织在企业中的职责就是为企业运行和发展中的问题提供技术解决方案，并帮助企业盈利。
因此，企业赋予研发组织的“责”就是企业发展中碰到的“技术问题（problem)”，也就是我们常说的“需求”。
研发组织要解决接到的研发任务，就需要调动资源（人、钱、物），按照研发的规律决定研发计划，努力完成任务。对于人、钱、物调动的权力，就是行使职责所需要的权力，但是研发组织并不能直接产生盈利，而是需要从企业获得资源，因此，企业配备给研发组织相应的资源和对资源的支配权就是一次赋权过程。
研发组织经过内部的一系列研发活动，产生的技术成果，就是“利”。
所以在大研发体系中的赋责就是提出需求，赋权就是配备研发资源，分利就是对技术成果的管理。
所以从研发组织与企业其他部分的相互关系角度，就可以把大研发体系中的管理问题归纳成三个方面：1.责怎么领（需求怎么来）；2.权怎么赋（资源怎么给）；3.利怎么分（成果怎么归属）。
一.（一）责怎么领
大研发体系的责（技术需求）是整个研发体系的立足点，对这个的理解不透或不到位，会导致各种各样的衍生问题。
既然是领责，就必然涉及从“谁”那里领的问题。
首先，研发组织是负责解决需求的，需求本身必须来自于企业的运营单位。从企业的运营角度，能通过技术的开发解决的问题无非这么几类：
1.现有产品或技术的性能提升，提高竞争能力。要么卖更高的价格获取更多的利润，要么降低了成本，获取了更多的利润。
2.设置技术障碍，增加竞争对手的成本，从而让自己公司的产品获取竞争优势，抬升售价，获取更多利润。
3.针对将要采购的产品或技术，研发备胎，作为竞争手段，获得谈判中的筹码，压低价格。
4.打通新业务模式的关键环节技术，拓展原有产品的应用方式和应用领域。
5.探索新的技术，潜在可以发展为新行业或新产业的技术，为企业的长远发展占据有利市场地位（蓝海战术，本质是把竞争对手消灭在萌芽中）。
可以通过技术解决的问题或需求很多，性质跟以上5种大同小异。我们就以这几类问题为例，不再一一列举了。
需求1，得利的是企业内部的具体产业部门。而且效益是显性的，其中提升价格显性指数强，降低成本的显性指数较弱（换句话说，容易被产业部门赖账）。
需求2，得利的是企业内部的具体产业部门。而且效益是隐性的，这属于高阶玩法，对于产业部门的决策能力要求很高，如果研发组织主动做好事的结果一定是被产业部门“赖账”，因为他们看不懂。
需求3，得利的是企业内部的具体产业部门。虽然效益名义上是显性的，但是往往只在博弈的时候有用，碰上“渣男”（缺德的产业部门领导），跟所有的备胎命运一样，用完就扔。博弈着急的时候，恨不得你马上就把成果做出来，要啥给啥说啥都行，博弈有眉目了，马上玩失踪。
需求4，要在企业的战略层面，发现市场运行的短板，通过开发新技术成立新的产业，与原有的产业或产品形成1+1大于2的业务发展效果。得利体现在公司整体业务的拓展，这种效益在公司层面是显性的，但对于原有的产品或产业部门是隐性的。
需求5，得利的必然是公司的业务拓展，获得更大的发展机会，效益长期看是显性的，短期看是隐性的（创造了可能性）。但对于原有的产业部门，反而是“有害”的，因为需要从已有的产业部门“榨取”利润，用来转移支付新产业的开展。
俗话说，谁的孩子谁抱走，谁的需求谁领走。技术开发成功后得利的那一方，就是该需求的主责方。
从上面的分析，大家应该可以感受到，所谓的大研发体系管理的核心就是通过制度设计和文化认知建设，让企业内部的主责部门承担起自己该有的责任，定义出正确合理的技术开发需求，同时遏止产业部门领导做“渣男”的冲动。
对于一个希望通过技术创新建立竞争优势的企业来说，那些无能力或不愿意主动制定合理的、用于支撑自己产业发展的技术需求路线图的产业部门领导，该怎么处置，不用我明说了吧。
对于需求1，不需要太复杂的管理能力，只要愿意，产业部门肯定能定义出来，不做纯粹属于懒惰。
对于需求2，需要产业部门有外向型思维，能时刻关注竞争对手的动态，制定相应的策略。
对于需求3，需求、思路、做法、判断标准，都是秃头上的虱子，唯独考验的是产业部门领导的人品。
需求4和需求5，主责部门都是在企业层面，往往需要企业的一把手或董事会做出相应的决策和判断，而不是下面的现有产业部门。这部分需求在日常工作中由哪个组织来负责收集和整理，各个企业有各种不同的做法，但是无非是叫做战略部、战略委员会等等，大都划到战略一类。但是不管叫什么，或赋予什么部门，清晰明确的需求4和需求5的定义，是战略部门或组织的核心交付物。
如果负责战略的组织或部门，天天分析各种国际局势，时时高唱各种新业态新模式，就是不把自己的分析结合企业实际，落实到具体的需求4或需求5清单上，这种战略部门是个什么货色，也不用我明说了吧。
至此，我们分析了整个研发体系的基石（需求）的核心作用，以及对各种不同的需求进行定义的主要责任方。我们这里强调主要责任方意味着，这些主责方是牵头的，而不是让他们独立完成（拍脑壳，闭门造车）。决策过程中可以包括各方的意见（尤其是研发组织和市场部的意见），做各种调研分析和讨论，但最终拍板负责的必须是这些主责部门。
注：研发单位的技术自由探索功能主责部门是谁呢？这个问题可以换个问法，研发单位是为谁做的自由探索？如果自由探索的领域是寻找新的业务领域，其天然服务对象是企业总部，因此必须是由总部出资并授权的研发活动。如果自由探索的领域是已有产业部门的业务范围，对于一个稳定运行的产业或产品线，有那么多自由的探索空间吗？业务逻辑已经清晰明了的情况下，什么该做什么不该做还不清楚吗？如果有，一定是决策链条上某个环节的失职，而不是需要研发单位越殂代疱充大头。
基于上述讨论，我们可以得出结论，大研发体系建设的首要任务：明确短中期技术需求制定的责任方为产业部门，明确中长期前沿技术需求制定的责任方为企业总部层面的战略组织或部门，明确这两类部门制定相应技术需求规划的标准和流程（纪录在案的年度时间节点、任务和交付物）。
一.（二）权怎么赋
前面提到，“权”就是对各种研发资源的使用权。这里需要强调资源是指广义的“资源”，即一切可以通过资金换取的资源，包括设备、设施、场地、人才、已有成果、图纸等等，也包括其他的资质类的资源。
有了“责”，跟责对应的就是“权”，责是权之魂，权为责所用。主责部门确立了需求清单之后，自然而然就需要为自己的需求买单，做好相应的预算。准备好让渡相应的资源使用权给承担相应的研发任务的组织或部门。
主责部门基于明确的需求清单，与通过筛选之后确定的相应研发单位之间要有明确的“责、权”交接，在赋予研发单位解决技术需求责任的同时，给与相应的资源使用权（即研发资金），做到权责统一。
对于需求类别1、2、3，出资单位就应该是相应的产业部门。各个产业部门每年在完成相应的需求清单制定过程中，应该有制度化的安排，同步完成相应的资金预算研判并做列支，无合理预算列支的需求是假需求。基于合理的投资回报率核算，预算的额度应该与该需求对应的业务价值匹配，核算时需要同步计入项目的成功几率或试错成本。
同理，对于企业层面的战略性技术布局需求（需求类别4、5），应该由企业的总部预算覆盖。希望开展此类业务的企业，也必然需要在总部层面有配套的需求研判机制和资源调拨机制（实操层面有具体的年度时间节点、地点、任务、责任人、交付物等等细节）。
在实操层面，各个企业往往没有一个专门负责技术相关战略的部门，同时技术与产业互动的长期趋势和布局又具有高度的专业性，需要对技术在行业的发展趋势有长期的观察和深入的思考才能给出有价值的判断。因此企业里的中央研究院（或前沿技术研究院等类似组织）往往被企业赋予了相应的职责，在这种情况下，这些中央研究院也必须建立起相应的信息收集、筛选、整合和决策的机制，以帮助企业能更有效地承担技术战略布局的责任。相应地，为整个公司的发展探索技术长期战略的“权”也应该被赋予中央研究院，在实操层面往往表现为预拨的由研究院自主支配的固定研发经费（全口径，包含人工费用）。例如，GE公司的中央研究院经费构成中，60%是来自于子分公司的横向经费，研发任务完全由子分公司定义，研究院的技术业务总监负责管理；30%经费属于前沿技术开发，资金由GE总部承担，但是研发任务需要跟有相关性的子分公司共同商定，研究院有决定性的话语权；10%的经费属于战略性尖端技术探索，完全由研究院确定（有一个战略科学家群体和工作的机制流程），资金也自然而然由总部承担。在GE的案例中，中央研究院的战略科学家群体和领导层承担了GE集团公司层面的技术战略部门的角色（权、责）。（注：GE公司的资金是全口径核算，以上的比例严格代表了包括人力资源的整体研发资源分配比例）。
关于显性效益与隐性效益。无论显性效益还是隐性效益，最终都是企业的真金白银。但是其中围绕显性效益类别的决策，逻辑链条浮在水面之上，只要认清上面所述的业务责任和决策逻辑，并不需要太多的“智商”就能明白应该怎么操作。而隐性效益类的需求，往往对企业相关人员的智商和专业认知有一定的要求。因此，企业与企业之间的竞争，最大的差异也往往体现在隐性效益类的需求和研发决策上。对于“低智商”类企业，往往死都不知道自己是怎么死的，属于传说中的被降维打击。至于总想“当渣男”的企业或产业部门，除非家里有矿，否则迟早被社会淘汰。
注意：在原有的计划经济时代遗留下来的直接经费和间接经费（人员费等）的分类，造成了很多认识上的混乱，也给很多研发组织的管理造成了很大的困扰。企业是一个经济体，所有的支出大体分为两类，固定资产支出和费用支出（本人非财会人员，不接受财务专业的抬杠），其中固定资产支出适用一次支出，但按照折旧计提的方式入账，费用则边用、边消耗、边全额入账。从这个维度，所有的人员费用和材料消耗没有本质的不同，从企业与研发单位之间管理的角度，不应该区分。另一方面，作为研发过程， 真正宝贵的是研发人员的时间消耗（本质是脑力消耗），而不是买实验材料那仨瓜俩枣儿，在这个问题上，有太多的愚蠢至极而且毫无意义的纠缠不清（有人无意，有人故意），白白消耗了大量的公司层面和研发组织内部宝贵的管理资源。
这一点是目前科研大环境的短板之一。所有人都有“解决猪的问题，但是让狗买单”的思想倾向。问题的根源与过去几十年直接经费和人员费分两条线管理有一定关系。
在计划经济年代，人员费往往由国家或总部作为固定花费支出，没有计入研发成本。在实际操作中，产业单位也往往只需要考虑研发项目的直接经费的支出。即使是提供技术解决方案的第三方，在中国往往是各个大学或国家拥有的科研院所，他们的人工费也往往由财政直接覆盖。导致企业跟大学谈研发任务的时候，也是几十年如一日的只考虑直接经费，对于研发中最重要的也是最大头儿的资源消耗（人力）却不管不顾。这直接导致了两个恶果：
1.市场上的所有人对研发中真正核心的人才价值缺乏下意识的尊重（嘴上漂亮话大家都会说），很多人的思维逻辑架构都已经潜意识里把人的价值忽略了，需要提醒才会“哦，对对对”。对你个头啊。
2.在研发项目的管理过程中，人力资源的量化管理长期处以畸形状态，各种扭曲的奇葩操作被衍生出来。
所有的研发单位领导，永远在为人员费奔波；要么研发项目做一个亏一个，无论成果多么的漂亮；要么在财务报表上做手脚，想方设法把人力成本塞进去；市场上还流传者各种各样的应对财务审计的心得、甚至于经验分享（比如如何把一个专家的费用拆解到几个普通员工的名额上），殊不知这些财务审计的底层逻辑本身就是个大笑话，是整个体系扭曲的结果。而到了项目层面，有影响力的项目经理永远在寻找各种各样的借口要求更多的人员配置，哪怕是要来了人给自己端茶倒水也是好的，反正不花项目的钱；甚至于科研人员本人，也愿意到人浮于事的项目上去，反正同样有工资领，人浮于事的项目反而活儿少，责任轻。
放眼全球，有独立核算的经济主体，包括跨国公司，大型的民营企业，基本都能做到：谁的事儿谁出钱，全口径核算（包括量化计量的人员费消耗）。
有人狡辩说人员费不好计量，难以做到准确，这些的都是非常幼稚的认知，或者脑子进水了。能不能算的准是技术问题，算与不算是性质问题，岂可同日而语。无论多么不准的计量都比假装看不见要强。
一.（三）“利怎么分”，即成果的管理
任何研发项目必然自带探索性质，因此，研发过程中，必然会得到一系列的信息和基于信息形成的判断和结论。这些一系列的结论链接起来，最终可能形成一个可操作落地的技术方案，也可能在某一个环节形成此路不通的结论，这些都是研发的成果。
在项目的执行过程中，必然会借用到一些原来就存在的知识资产，这些资产有可能是研发单位之前自己拥有的知识资产，也可能是不相关的第三方的知识资产。
同时，通过项目的执行，也可能形成了一些新的知识资产。
对于一个“客户”（产业部门或企业总部）根据自身的技术需求，定制化开发的研发项目，项目中形成的技术方案或者是项目失败形成的结论，其使用权天然归出资的“客户”，因为客户可以通过使用这些结论，做出自己业务上的合理决策，这些不管是成功还是失败的结论，相当于是一个咨询答案，而业务部门对于自身的技术需求下一步要采取的措施，需要这些“咨询”答案做决策。
研发过程中借用到的已有知识资产，如果在最终的技术方案中，也会用到这些知识资产，那么，企业在以后的成果落地过程中，必须考虑购买这些知识资产的使用权（注意，不是产权）。
研发过程中形成的知识资产，其产权和使用权的归属，取决于形成过程中哪部分的贡献大，如果研发单位自身过去的知识和经验积累贡献大，产权归研发单位；如果客户出资所对应的研发活动贡献大，则产权归出资方；如果无法清晰界定的一般可作为共有产权，或遵从双方的约定。（注：在一些欧美国家法律体系中，知识资产的产权自动归发明人个人，需要一系列的法律权利让渡安排才能归属企业）。但是无论何种安排，出资人一般自动获得使用权，除非另有特殊约定。
为了后面关于成果管理的讨论方便，我们假设所有的项目执行中产生的新知识资产，产权归属于出资人。
至此，出资方（即技术需求主责方），通过对研发和技术的投资，获得了一个可以落地实施的解决方案，研发组织完成了研发环节上的所有任务，并交接完毕，完成了整个过程的逻辑闭环。在此之后的业务活动纯粹属于投资和生产范畴。
从技术需求主责方的角度，为了成功进入生产运营环节，在技术开发环节的总投入包含，1.整个研发项目的过程中支出，2.落地成果所必要的已有知识资产使用权的购买。因此，在前端，需要做出相应的准备。（知识资产的产权的购买属于投资性质，无关成果落地，这里不做讨论）。
而对于一个企业来说，经过一段时间的研发投入，必然会形成众多的知识资产，如何通过统筹安排，优化这些知识资产的所有权和使用权，最大化它们的价值，并减少管理成本和风险，是一门学问。很多企业，尤其是有众多法人实体，且跨国运营的企业，往往在经历了惨痛的教训，交了不菲的学费之后才认识到统筹管理知识产权的重要性。
系统化、专业化的知识产权管理体系和理念的形成，标志着大研发体系建设完成逻辑闭环。
某跨国公司在业务扩张和全球化的过程中，一开始并没有刻意设计知识产权的管理体系，任由各个子分公司和法人实体，在项目执行的过程中自行决策和谈判他们投资的研发项目形成的知识资产的归属权和使用权。当公司的业务横跨很多个国家与地区，拥有成百上千个法人实体之后，知识产权的使用逐渐演变成了一场噩梦。
首先，知识资产的定性和归属是个法律概念，不同国家和地区的管理理念和模式不全一样。
其次，各个子分公司和法人实体对知识产权的管理能力和经验参差不齐，形成了很多短板和漏洞。
第三，作为一个集团公司，存在的价值就是资源共享，最大化共同的收益，因此各个子分公司拥有的知识产权在全集团的共享是个必然趋势，但是势必造成各种来回的交叉授权。
第四，每一次的知识产权授权行为，都会牵扯到授权双发的税务管理问题。上千家法人实体，几万个专利，所产生的这种交叉授权关系和潜在的税务合规风险迅速膨胀到一个天文数字。
经过评估，公司重新设计了知识产权管理结构，拿出一大笔资金，在全球把所有子分公司所拥有的知识产权归属统统收购到总公司名下，再由总公司统一授权给需要使用的子分公司或法人实体（如下图）。之后，在整个集团公司内部，所有新申请的知识产权都唯一归属到总公司名下，除非极其特殊情况下经总公司评估和批准，否则不允许有任何例外。但是各个子分公司跟自己业务相关的知识产权，仍然在集团公司内部的管理系统中做出相应的管理权限标记，在各种评估和管理操作上，赋予被标记的子分公司决定权（对外授权、转让、放弃或打官司等等），但是法律层面的操作，全部由总公司完成，子分公司法人不体现在对外的任何文件上。
在这种管理结构之下，产权简洁明晰，法律关系边界清晰，风险完全在掌控之下，而且节省了大量的交叉授权带来的税务成本。
第二部分：小研发体系
不同于大研发体系，小研发体系是由一个专职的研发组织来承载，因此，小研发体系的设计必须同步考虑组织结构设计，体系与组织互相成就，互相影响。研发组织具有所有常见组织的基本内核，基本分为三大类：核心业务，队伍，运营辅助。
小研发体系的责权利体系建设主要体现在它的核心业务（即研发活动）中，这部分是整个研发组织区别于任何其他组织的关键所在，也是研发组织之所以存在的基础。因此，所谓研发体系的搭建就是研发业务管理体系的搭建，研发体系的管理就是指研发业务的管理，和围绕研发业务特点对其他的辅助职能提出的配合要求。我们下面重点介绍研发业务活动的责权利设计逻辑和管理逻辑。
研发活动相对于生产活动，更加依赖人的品质和能动性。在生产部门中，生产主要依赖于生产资料，人通过管理和操作生产资料完成生产活动。而在研发单位，科研人员本身就是生产资料，其管理受科研活动特质的深度影响。因此，我们后面顺带介绍一下研发单位的科研人员管理。
运营辅助功能，如IT, 财务，法律，后勤保障等等，虽然需要考虑服务于研发单位的业务特殊性，但就这些职能本身，并不会因为服务于研发单位而改变它们的工作内在逻辑。因此，我们讨论研发体系建设的时候，并不必过多涉及这部分内容。
二．（一）管业务：研发活动的权、责管理
小研发体系是研发组织内的责、权、利管理。因此，管业务就是围绕研发活动的责权利展开。
1）权责的交接和分解
小研发体系的第一个环节，是与大研发体系的责任（需求）交接机制。即产业部门的技术需求如何通过一系列的沟通和筛选决策机制，成为研发组织内部承接的一个个有清晰和明确定义的研发任务。
对接与沟通一定是通过人与人之间的互动完成，因此，大研发体系与小研发体系的责任交接机制就是要：1.明确产业部门和研发组织对接的具体负责人（两边都要)；2.明确对接的过程、内容、交付物和年度时间节点；3.这些交付物的表现形式就是逐个精确定义的可承接问题（problem，责）清单，以及每个问题对应的研发经费（权）安排。
研发组织内部这个与产业部门对接需求的负责人，我们暂且称为技术业务总监。从研发组织承接到一个研发任务（从这里开始，我们可以称之为项目）开始，就启动了研发组织内部的责任“切分和分包”机制。
为了准确理解研发活动的责权利，我们首先得对企业的研发活动的本质做一个准确的理解。
当一个产业部门有一个技术需求的时候，这个需求的表现形式是有一个技术问题（拦路虎，problem）没有解决方案，导致无法做进一步的业务决策。这个问题可以是一个很大的复杂问题，比如航空母舰怎么设计；也可以是一个很小的具体问题点，比如瓷砖的表面平整度怎么提高。当这个问题交给研发单位的时候（当然连同研发经费一起），希望研发单位通过内部的研发活动给出一个方案。考虑研发结果的先天不确定性，通过研发之后，给出的结论可能是：1.这个问题按照技术指标要求解决不了；2.这个问题有能满足指标要求的解决方案，并给出方案。
研发组织需要为自己的“结论”负责，无论结论是1 还是 2。如果结论是 1，而且结论可靠，那么产业部门就可以依据这个否定的结论，否决围绕这个技术需求的投资计划，获得了宝贵的确定性，把业务重点转向别的方向。如果结论是2，有解决方案，而且结论可靠，意味着这个方案确实能满足初始定义的技术需求，那么生产部门就可以以这个技术方案为基础，做出进一步的产业投资，形成“产品”并产生预期的经济效益。
技术业务总监需要把一个个定义清楚的“问题”通过筛选机制，交接给研发组织内部具有解决问题能力的研发专家，筛选出的合格研发专家如果也同意承接该任务（“问题”，责）和对应的研发资源（权：广义的资金调配权力）并按流程完成录入管理系统，则一个研发项目就完成了定义和立项，该研发专家正式成为“项目负责人”。如果承接的是一个复杂的大问题，这个项目负责人还可以把这个大问题合理地拆解成一系列的小问题，再把这些小问题分配给他认为具备相应解决能力的小研发专家（项目课题负责人）。
拆分出来的并列的小问题之间，往往由不同的责任人分别承担。沿着时间纵轴，大问题还可以拆分成一系列前后互相依赖的小问题，往往需要按照前后逻辑一一顺次解决。这个问题拆分的过程，就是一个拆责分责的过程，换句话说，每一个项目负责人或课题负责人，都是真正意义上的“负责”人。反过来在执行过程中，每个“负责人”通过得出自已研发任务的结论，累积成整个项目的结论，回馈给“交办”的客户，完成整个研发任务的逻辑闭环。
2）利的定义和管理
由以上讨论我们可以看出，整个研发活动的“利”就是研发的结论，能被客户拿去做决策和使用的“结论”。而绝不是什么狗屁的专利、文章、示范项目等等，那些都是锦上添花的额外收获，或者是研发的资源。在这一点上，只有那些真正在市场上拼刺刀的产业部门才有深刻的认识。
对于那些以炫耀为目的的研发投入，领导们最喜欢看到的可能就是投入XX个亿，规模XX万吨的示范装置。针对这类项目，当被问到，这么大的投入，能说明什么问题？得出什么结论？往往干的人一脸懵圈儿，整个决策简直弱智透顶。我们并不反对建设大装置，也不反对投大的示范，关键是针对所要回答的问题，这个投入是否必要？是否唯一的选项？这种花架子类的投入，多发生在两类企业里，一类是“反正不是花自家钱”的企业，大家都懂的；另一类是对研发的探索本质缺乏了解，把“干活儿”当成了研发的企业，以为活儿干的越大越多越牛X。
3）责权利的互动
在这个拆分问题、“分责”的过程中，必然伴随者“分权”的过程，即为了解决问题，相应的项目负责人或课题负责人，拥有支配所给与的研发资源、选择最佳验证方式和验证资源的权力。因此，我们一再强调，项目中的每一个工程师，都是一个权责主体，需要发挥自己的聪明才智和主观能动性，针对所负责的“问题”（责）用最快最有效的方式（权）得到可靠的“结论”（利）。 大家研发能力的高低就体现在，1.是否能对自己负责的问题得到可靠的结论；2.在得到可靠结论的前提下，能以更高效的资源消耗得到结论。用通俗的话讲，如果结论是该问题解决不了，那能否用最小的代价发现真相？如果问题最终能解决，能否用最节省的路径尽量少的研发资源找到解决方案？作为技术业务总监，这两条就是挑选项目负责人的标准（在这个大原则下可以细化成很多特征），而作为项目负责人，这两条也是他们挑选项目组成员的标准。
注意：这里项目负责人经常犯的错误是把分责过程弄成了分活儿过程。我们一再强调，科研活动（例如：做实验，查资料）的目的是科研结论（说明了什么问题），因此每一个工程师在项目中的角色是认领需要解决的“问题”，而不是认领一堆的活儿（比如做实验）。实验是手段，结论才是目的，而一旦手段与目的颠倒（或者不知道目的是什么），“干活儿”本身变成了衡量标准，无论对项目还是对个人，都会产生极大的资源浪费，甚至导致项目完全失败（资源总是有限的）。在日常科研管理中，本人非常痛心疾首的就是碰到“工作极其努力，夜以继日以做实验为目的”的工程师，对组织对个人的发展危害极大。
基于权责对等的原则，项目负责人必须有权根据项目的问题需要，挑选合适的工程师，同时给与所选合适工程师他认为合适的细分“权责”。从这里可以看出，研发组织里的工程师们本质上是一个一个的“资源”。这些资源要想发挥最大化的作用，就必须按照项目的需求来匹配，即项目需求决定人员组成。
4）研发业务（软件）与研发组织（硬件）的互动关系
研发工程师作为一种研发的资源，需要保持高度的流动性，流动性越高的资源，其发挥作用的效率就越高。但是，任何的研发组织，其中的研发工程师都是划分成一个一个更小的组织单元，实现人员的管理，是一个天然的稳定结构。组织的稳定性与研发活动对资源流动性的要求天然矛盾。
这就需要对组织里工程师作为人的属性和作为资源的属性做分离处理。工程师只有花在研发任务上的时间和精力才是研发的资源，自然属性的“人”本身并不是研发的资源。这种划分类似于资产的归属权和使用权，归属权是一个整体，是死的，而使用权是可以分割调配的，是活的。下表是对研发中的三种核心要素的比较。
项目需求
人的资源属性
人的资产属性
研发任务
研发时间
组织身份
解决不确定性
高流动性，可调配
稳定，不易变动
表1 三种核心研发要素比较
项目内部的管理核心就是对这三种研发要素的合理匹配。这里需要明确一点，研发组织的核心责任是解决技术需求，因此，资源的调配必须以项目需求为核心来完成。而研发组织的内部管理机制的设计，就是要反映研发项目需求的核心地位和围绕项目需求的研发资源调配机制，从而实现项目责权的统一。
对于这三种研发要素之间关系的深刻认知是设计研发组织内部项目管理机制的基石。研发项目管理是个分责的过程；人员的组织关系属于“资产产权”的性质；项目负责人对研发人员的调配，类似于资产使用权的购买。
由于研发活动高度依赖科研人员的主观能动性，很多吃瓜群众往往难以正确理解科研单位里面的管组织与管业务的区别，更有甚者，直接把管业务和管组织完全混为一谈。
有很多研发组织的管理者，也对这三者要素之间的地位和约束关系理解不到位，把管项目与管组织混淆起来，极端情况下，甚至出现以管组织代替管项目的最糟糕情形。
以管组织代替管项目这种现象在我国的体制内单位中最为常见，而且也深深影响了整个社会的管理习惯。组织死的，项目是活的，是两种截然不同的管理原则。这种现象的出现也有整个社会“官本位”文化的推波助澜，谁都愿意到外面炫耀自己管多少多少人，而不是管理一个多么重要多么复杂的项目（主要是社会上的吃瓜群众们也听不懂）。
5）项目的跟踪评估机制
项目组毕竟是由人组成，一旦设立，就会产生一直向前的执行惯性，甚至脱离它作为“获取结论的手段”的定位，向组织化方向演进。因此，研发组织必须有专人负责的、刚性的定期项目评估机制，对项目继续的必要性和内容的合理性随时做出必要的判断和终止决策，以制衡项目组天然的组织化倾向，进而导致本末倒置，让研发资源失去流动性。
关于项目的日常管理，绝不应该忽视项目的探索本质，技术业务总监对项目的目标结论的有效性应时时关注。我们大部分人的认知是定期看看项目的进度，看看任务完成的怎么样了。大部分的日常项目评审内容也确实是根据项目计划评估项目团队的执行情况，并根据项目碰到的问题从研发组织层面协调资源予以支持。但一个永远隐含的项目管理和评估目的是及时决策：一旦有支撑信息出现证明预期的结论为否，项目应该随时被终止以节省研发资源。
目前国内市场上的项目管理一个很大的误区是假设项目肯定能成功，与研发项目的探索本质南辕北辙。项目管理普遍是以检查“干活儿”为导向，而不是以检查“结论”为导向，即：项目一旦立项，就必须按计划完成所有的规定动作和任务。如果是结论已知的工程类项目，这种做法无可厚非，因为执行力就是省钱，只要执行好就一定能成功。但是对于探索性质的研发项目，这种做法就危害巨大。我们不可能在要求项目组必须完成所有规定动作的管理方式下，同时要求项目组寻找最优的验证路径用以时时判断项目成功的可能性，以遵循研发的探索本质。
二．（二）管组织：就是管理人的职业需求
从业务本质上说，研发组织里的工程师，作为一个整体，都是为项目服务的资源池。如果类比生产单位的话，研发的工程师们就相当于是工厂里的生产线，而研发的成果就相当于生产线上下来的产品。从这个角度，生产线都是为产品服务的。
但是，这些产线又是有主观能动性、自我管理的“产线”，因此，工程师群体在完成研发任务、为企业创造价值的过程中，同时也是他们建立自己的职业生涯、实现自我价值的过程。另一方面，他们又是能学习的“产线”，随着一个个研发任务的执行和反馈，有不断地自我总结、自我学习和自我提升的需求。
从企业的视角看，服务于项目需要、最大化人员的利用价值是主要目的，工程师们获得经验、反馈、能力、成长，变得更有价值，从资源增值和储备的角度，是手段。
从工程师的个人视角看，通过项目的执行，获得经验、知识、能力、认可和回报才是目的，把项目做好为企业创造价值是实现自我价值的手段。
两个视角从过程上看是一致的，但是在作选择时是不一致的。因此，对于研发组织里面工程师的管理，就是要平衡好企业目的与个人目的之间的关系。
研发组织内部部门的设立，往往是基于人员的管理和成长需要。需要担负起每个工程师的招聘、培训、辅导、考核、个性化的发展和晋升等等，同时研发组织还需要为自身的发展培养人才梯队以搭建管理体系，这些都需要组织内部的“部门”来完成。
从项目的角度，希望组织越扁平越好，这样有利于资源的流动和调配。
从人员和组织发展的角度，希望组织结构化，这样才能形成一个有机的整体，保持组织发展的稳定性和长期性，同时为战略性决策奠定组织基础。
最终，研发组织作为一个组织，也是有“生命”、有生存意识的。如果所有的决定和流程都只是有利于项目，有利于企业，而研发组织自身的利益和长远发展却得不到保证，那么这个研发组织也不可能发展的好，反过来又会损害企业的研发能力和创新能力。整个研发组织的“生存意识”也是由内部个各个部门的生存意识叠加组成，所以在各个部门层面，这个矛盾同样适用。
如何能平衡好个人、部门、组织的长期发展诉求与项目的阶段性、具体的、灵活性的诉求，有许多不同的做法和管理技巧，比如矩阵式管理、内部创业制、自由组队揭榜挂帅、赛马制、重点攻关等等，都是在项目需要和人员管理之间寻找平衡。没有一个方式是包打天下的完美方式，作为研发组织的管理者和研发体系的设计者，需要对项目管理和人员管理之间的差异和关系有深刻的理解，才能做到因地制宜，灵活举措。如果混淆了管项目与管组织，甚至于以管组织的方式管项目，最终一定异化成“因人设事”，组织和部门变成绑架研发决策的家天下（因为有这些人、因为这些人是XXX专家、因为这些人又有了话语权，所以就要设立XXX项目）。最终的结果是整个研发体系效率的大幅度下降。
归纳第二部分的讨论，小研发体系的搭建由这几方面构成：1.技术需求的责权利的承接分包机制；2.研发资源（人员）的归属和调用机制；3.研发项目的全生命周期评估管理机制。4.如何把项目的“利”与组织和个人的“利”合理地结合起来以高效地调动人的积极性，就是考核机制。组织和个人的考核论题内涵复杂丰富，我们另文专门论述。
第三部分：总结
整个研发体系的建设归根结底是对研发决策和研发执行过程中责权利的深刻理解，并基于责权利协调一致的原则，设计这个组织的所有相关管理机制和流程，包括企业层面研发组织与其他业务部门之间的权责利协调机制和研发组织内部围绕研发活动本身的权责利划分与协调。
三．（一）
负责搭建大研发体系的是企业科技创新的主管领导（也即之前文章提到的发起筹建研发组织的1号种子）：科技创新的主管领导是把科技体系与整个企业的运营融为一体的人。如果一个企业不大，业务相对单一，那么企业的总经理就是科技创新的主管领导，如果企业业务构成复杂且体量庞大，那么就有可能有一个专职的主管领导。
主管领导必须能深刻理解科技创新是企业的一个功能，不是一个独立存在的业务。科研部门负责探索，厘清风险，提供方案和选项，然后由业务部门依据科研队伍的结果，结合业务上的非技术因素一起，制定投资和业务计划，从而实现企业效益的提升。在这里必须强调，科技创新是为产业服务的，是替产业部门解决当前问题或探索未来道路的，但“路”要产业部门自己去走，企业的效益也必须由产业活动来实现。
产业部门作为这个链条上的甲方，必须负责为乙方（研发部门）提供产业发展方向的指示，如果产业部门在这方面没有合格的知识储备和战略思考，就必然会出现乱指方向，或不作为要求研发部门自己定方向的现象。造成的后果就是研发部门出了一堆成果产业部门没法落地。所以，如何把业务部门打造成研发创新链条上合格的甲方是主管领导的重要职责。如果一个科技创新的主管领导认为自己就是要把科研队伍管好，那就是把自己降格为研发组织的负责人了。所以当一个企业的领导追问研发部门的直接经济效益的时候，那么整个公司的创新体系，尤其是产业部门的创新职能一定出现了问题！
因此，作为整个企业创新体系的负责人，如何提高企业（注意，不是研发部门）的创新效率，创造更多的经济价值是核心责任。需要在工作中紧紧抓住产业部门这个创新链条的龙头。如果产业部门在创新战略的实施上有任何闪失，造成的后果都是不可弥补的。
那么，作为创新体系的负责人，在主抓产业部门创新职能时需要注意什么？
1.深刻理解产业部门在创新体系中的头尾作用。产业部门才是创新需求的提出者，任何没有产业部门认可的创新活动都是无源之水，无本之木。所有的创新成果要由产业部门（全套商业功能）来实施，如果一个成果没有一个对应的产业部门，必然无法对本企业创造价值 （技术转让/许可也是通过广义上的“产业部门”—即技术受让方—产生效益）。
2.对产业部门实施正确的考核和激励手段，促使他们发挥创新龙头和龙尾的作用。作为龙头，要考核他们是否有高效的需求收集和筛选机制，提出的研发目标是否契合业务发展战略，是否了解市场和竞争对手的前瞻布局，是否有效利用企业内外的创新力量。作为龙尾，要考核产业部门是否有成熟稳定的研发成果评估和接收机制，是否了解新技术新产品的生产推广规律，相应的队伍是否完善。
创新体系建设常见的误区：
1.认为创新是研发部门的事儿，导致产业部门在创新链条上缺位，整个体系无法发挥作用，体系运作难以持续。
2.考核指标错位。比如把产业部门当成创新活动的主体，用考核研发部门的指标考核产业部门。比如考核产业部门的知识产权数量（专利数），导致产业部门与研发队伍在本是一家人的情况下争抢知识产权的冠名或名义归属（实际都应该是归属整个企业）。或者走另一个极端，用直接的经济指标考核研发部门，导致研发部门热衷于自立门户，进入生产销售，对服务本企业的产业部门不积极不热心，甚至把产业部门当成竞争对手。
3.做不到结合本企业所在的行业特点，盲目地与别的行业的企业攀比对标。一个企业所在行业的发展曲线一般符合下图所示的S曲线，在不同的发展阶段，技术演进的特点和作用不同，企业需要采取不同的风险和投资评估机制，技术发展的曲线会略早于行业曲线。在早期，技术/行业前景高度不确定，需要多点布局，小心试探，积极求证，避免冒进。中期，行业/技术爆发，行动慢是最大的风险。后期，技术/行业走向成熟，需求和回报相对明确，是企业运行的基础，但难以形成高回报的投资机会，决策避免掉入舒适区陷阱，固步自封，忽视新技术/业务模式的产生。
三．（二）
负责搭建小研发体系的是研发组织的负责人（也即之前文章提到的发起筹建研发组织的2号种子）：我们一再说，研发组织的负责人，必须对研发的内在逻辑有深刻的洞见（不能只是有很多经验而已）。既要基于研发活动的特质搭建合理的小研发体系：搭建合理的组织架构（分责）、设计合理的管理流程（分权）以及高效的奖惩机制（分利）；还要完成与大研发体系对接，与企业的其它部门形成融为一体的合作机制。最后，研发组织的负责人还必须是“人精儿”！这个社会毕竟是“人”的社会，如何管理好一个由人构成的组织，对人的认识必须深刻精准。
首先，负责人必须对人性有深刻的理解，工作安排如果符合人性，就很容易开展，如果违背人性就会寸步难行。当一个组织的职责和流程设定、或者工作安排出现问题的时候，组织负责人要能迅速地识别出是否由人性的因素造成，如果有，则必须首先解决和改变。
其次，负责人必须对自己组织里每个角色的能力模型有准确的认知，这样在安排人员时才能判断一个人是否具备胜任这个角色的能力、潜在的弱项是什么。对组织的弱点能有准确的判断和预估，在发展组织时，知道从哪些角度出发能做到事半功倍。
