主题：【原创】中国式研发管理 -- ericyu

项目组合和单个项目有什么不同？其实严格意义上项目组合可以看作一个大型的项目。单个研发项目相对而言，有较明确的目标和较固定的时间表；通常有项目负责人组织不同团队的人员组成临时项目组进行工作，并不具有固定的人力资源组织。而项目组合则通常是一个具体的组织结构，负责人对团队成员具有行政的指挥权。项目组合的目标也通常更普遍化，不那么容易量化。有时项目组合甚至是没有结束预期点的。例如之前提到的奶茶连锁店的研发中心中上海支持团队，就是一种项目组合的形式。

在英文中，有时候使用诸如：portfolio，program，platform，cluster等来描述项目组合。不同的用词当然给与的含义有所不同。Portfolio是项目组合的直译，通常用来指由不同目标项目因为某种原因而聚在一起，例如服务对象，适用领域，甚至资源类型等等。Program则常指几个具有相同目标的项目的组合，所以其实意味着一个大型项目。Platform是从资源角度出发，意味着其中的项目共享某一项资源，特别是智力资源；所以也可以翻译成“平台”；国内许多政府组织的项目就称为 平台项目组合。Cluster更多的用于指不同公司间合作的研发项目。

漏斗模型是研发项目管理的原理。在此基础上所有通用的项目管理方式和工具都可以为之服务。这里介绍笔者使用的项目进展汇报方式，如下表。

入选的创意点子 初步研究和研究计划 项目阶段 可以应用的成果 得到应用的成果

研发项目业绩的衡量，是一个困难的课题。笔者所在机构采取衡量最终成果的方式，直接计算项目产生的经济效益。不足点在于，研发项目的经济效益不易计算，尤其是以技术支持模式为主的研发中心，所产生的经济效益，往往是“硬”算出来的，不能反映项目工作状态。更多的是指导资源配置。这种方式在项目组合管理层面是有意义的，但具体到每个项目，不是很有意义。

笔者试图以项目中产生的点子数量，点子进入初步研究和研究计划的数量，点子进入项目阶段的数量，来衡量项目的业绩。不足点在于，每个人对什么是点子的认识很不同，而武断的统一对点子的认识，恰恰扼杀了产生点子的动力。所以，这种方式有待检验。

笔者所在公司的创新管理，以创意点子的漏斗模型为理论基础。在此之上建立了项目的关卡模型管理。相信很多人熟悉。

基本的理论就是创意点子在最初是很多的，假设有N个点子在项目过程中产生；随后要在关卡G0对N个点子筛选；然后M个点子进入概念发展（M<N），又称可行性初步研究；之后通过关卡G1，对其中的S0个点子提议进入详细研究，给出研究方案；通过关卡G2，决定对S1个子项目进行研究发展，并选择好的结果模拟实验；最终也许成功应用S2个创意点子。

这个理论是很浅显的，但是如何在项目过程中保证项目负责人以及项目组成员时时刻刻运用这个原理，确实很不确定的。难处来源于以下几点：

a)项目开始前，点子往往不着边际，这时G0相对容易执行。但越往后，执行关卡，删减不成功创意的难度越大。所以设计关卡决定人是很艺术的一件事。往往G0可以是项目组成员集体决定，G1和G2可以交给项目负责人。但G3必须是负责人的上司，而G4必须是关键利益相关团体，通常是运营部门。而这种设计绝不能是教科书式的死板。必须体会到漏斗模型的目的在于产生足够多的创意，但同时把好每一道关卡。

b)一旦项目开始，制定了计划和时间表，项目组就倾向于维护既有的计划。在此基础上继续产生新创意往往很困难。所以衡量项目的业绩，不能只盯住最终结果，开始阶段一样重要。衡量项目通过每道关卡的数量，也是很重要的。

c)研发项目每个关卡需要提供的“产品”需要细心设计，可以是项目会议，文献检索报告，结果演示，研究报告等等。

研发体制的核心是项目管理和创新文化。尽管中国新建的商业研发机构经常承担的是技术中心的角色，但是使用现代化的管理和文化，可以更好的发挥这些机构的功能，而且为将来成长为偏研发的中心打好基础。

研发项目管理和一般意义上的项目管理有不同吗？一般意义上的项目管理的典型是包含建设元素的项目管理，例如房地产开发，新工厂建设等等。这一类项目往往十分关注时间的管理和资源的管理。即项目可否在承诺的时间以承诺的成本交付。即使是不包括建设元素的项目，如某个新产品开发，一个体育盛会的举办，等等，也是同样的关注为主。而研发项目管理方式是为承载创新文化设计的。也就是说更关注结果的创新性而不是经济效益。

大多数时候，研发部门都不是真正执行创意的部门，而是负责产生创意的部门。尽管技术中心模式要求从业者更关心执行，但那不是研发的长处，那也正是严格意义上技术中心不能算为研发中心的原因。如果一个研发机构的体制，只是支持执行，这个机构更适宜放在运营的组织结构内，而不是独立作为研发的部分。

要建立支持创新的项目管理模式，关心的重点必须转移到创意管理上。这也就是我们通常讲的创新管理。如今，创新管理已经成为管理科学的一门新兴显学。这里笔者没有能力就创新管理进行全面的讨论，我只是以自己工作中使用到的为素材。

不会发图

管理必须有衡量，否则就流于形式。衡量的目的不是检查团队成员的业绩，而是着重团队的成绩。效率的计算是：工作量/团队成员数量。

如我所言，一个研发机构的领导人，可能没有时间进行每天的任务管理。当笔者从日常任务管理转为项目组合管理之后，的确将日常任务管理转交给了副手。但是无论是哪个层面的领导，都有下属。怎样对下属进行任务管理呢？

事实上许多很高层的领导，完全信任下属，不进行任何形式的任务管理。代之以的是目标管理，项目管理等等。但是这些领导常常不免感到：“我交给某某的一件事，为什么还没做好，也不是一件难做的任务啊？”所以笔者认为任务管理都是必要的，也许不是最主要的部分，但确实是必不可少的部分。

不少领导采取会议方式管理任务。即通过开会形成行动方案，然后在下次会议时回顾行动方案来管理。然而这种方式意味着会议的增加，而越是高层领导，会议已是不堪重负。所以我认为某种形式的任务清单和效率衡量会更有意义。

令人高兴的是，Outlook的Task Assignment功能也许是不错的替代品。这样就不需要特别准备一个任务清单了。领导只需要把任务assign给特定的下属，附以明确的交期。当然做一个衡量表仍然是必要的。

这里完成质量评分是基于领导的主观评价。而效率=期望的交期实际完成日期。所以正数表示负责人提前完成了该任务，负数则表示推迟。

很有启发意义

为了更好的描述笔者的经验，我必须举一个例子。而为了保密，我无法使用工作中的例子。而且笔者的工作内容，也许不容易为所有人理解。所以我试图创造一个简单易懂的例子。那么我假设一个奶茶连锁店的研发中心。在本文中，我们将管理这个中心。

假设该中心有一个团队，专门为上海地区的20家连锁店提供技术服务。该团队有3位同事，分别是负责配方的沪甲，负责设备的沪乙和负责客户体验的沪丙。团队负责人是沪组长。

沪组长必须对该团队的任务分类。方法有许多种。以下是笔者考虑过的方法：

1) 按内容划分为四类：配方，设备，客户体验以及团队发展。这里看客也许有两个问题：

a) 为什么要有团队发展？这是非常重要的分类。首先，团队领导的任务一定要在分类中表现出来，也可以取名为“团队管理”。对以研发团队，透明度和民主性是很重要的领导力元素，不可轻视。其次，团队必然有一些无法分类的任务，如果取名为“其他”，不是最好的名字。所以“团队发展”是个不错的名字。而且与其把领导任务划为“管理”，不如归到“发展”更亲民。

b) 如果团队成员有明确分工了，为何还要按内容划分？不如用各自的名字更直截了当。事实上，许多管理人员正是采取的这种方法。但按人划分的分类方法，对研发团队是极其不合适的。首先，研发团队一定要强调能力的全面发展，按人划分就画地为牢了。其次，技术工作往往无法分割。例如配方的技术问题，常常离不开特定的设备情况，于是研究配方的任务，必不可免涉及设备。一项任务开始时分为以配方研究为主，而随着任务发展，也许成为设备研究。这时不是都可以简单的将该项任务从沪甲负责转为沪乙负责的。所以任务还是要以内容分为好。而且任何分类衡量的应该是团队效率而不是某个人的成绩。

2) 按项目管理的关卡模型分类：点子，可行性，项目，应用等等。这种分类法将在介绍项目管理时再讨论。

3) 按任务所属操作步骤分类：备料，混合，加热，包装。这种分类往往是应用于有着明显操作步骤的大工业，或者如药物研发的合成步骤等。

4) 按任务属性分类：实验室模拟，仪器分析，文献检索，客户调查，等等

笔者大部分时间使用按内容分类。这也是大多数人的自然选择。因为这是最直观，而且往往是与团队成员挂钩最直接的方式。不足点在于，这种分类方式下的各项任务，其所需工作量是不直观的。属于某项内容的任务们可能是只要一天的，也可能是要一月的。工作量的评价往往是非常主观的。按任务所属操作步骤分类的优缺点基本与按内容分类接近。

笔者也在内容分类里包括了按任务属性分类的任务。这些任务的工作量相对容易衡量。其后，我们建立了完全以属性为基础的任务清单，便于团队效率管理。不足点在于，这种清单是离内容最远的方式。如果只是阅览清单，你无法得到该团队所从事的重点。

按项目管理的关卡模型分类，可以同时了解技术内容和衡量团队效率。但是这是一个过于复杂的清单。对于管理的工作负担要求较高。事实上，管理人员在使用管理项目的方式管理每天的任务。所以除非是很有必要或者初入门的研发管理人员为了练手，最好避免简单问题复杂化，不要使用这种方式。

如我所言，在中国的新建商业研发机构，采取偏技术应用中心模式是更贴近实际的。这就意味着，实时的日常的任务管理比长期的项目管理，对研发管理人员来说更重要。据笔者观察，即使在我所在的偏研发体制的机构里，日常内容也要占到一半的资源。如果是完全贴近生产部门的技术中心，更是几乎100%的是日常内容。

研发任务管理，如同所有的管理一样，没有特殊之处。就是列出团队成员的任务，规定交期，考察完成情况。而且如同其他管理，任务管理，应该是以“日”为单位的。每天团队领导都必须和成员讨论他们的工作任务。

有看客会提出，对研发从业人员进行以“日”为单位的管理，是太落后了。在中国，由于人力资源市场的极度活跃，研发从业人员往往年轻，缺乏经验。又或者，由于我国分配体制及社会保障体制的不完善，造成了工作人员的职业道德普遍不高，无法为内在驱动而努力工作。进而言之，即使发达国家的工作人员，也未见得就是个个职业道德高尚，为公司倾尽所有。人的惰性是天然的，这正是管理存在的必要性。正面的挑战人性的自大和懒惰，是任务管理的目的。

也许对以一个管理数十人的研发机构老总来说，进行以日为单位的任务管理是不必要的。但是老总们必须建立起以日为单位的任务管理模式，要求某些必要的下属遵循。建立在这种模式上的效率分析，更是老总们掌握你的机构必须的工具。