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

只是接触过SCRUM的理论，没想到可以支持我的经验。

我的理解SCRUM适用于IT项目。对于传统研发有没有意义？

软件开发最大的问题就是需求变更，更准确的说，往往在项目开始的时候，客户并不能清晰，完整的定义自己的需求。需求是一个逐步明确的过程，开发也是一个逐步完善的过程。

我不知道工业研发是否也要面对这样的问题，SCRUM最初只应用于软件开发，据说可以被成功地应用于其他产业。现在SCRUM通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。

研发工作，即便是偏近技术应用类型的，也难以做到每天都有进度。一个科研项目，从文献调研到可行性再到实施，再到最后成果，跨度往往是几年。比如实验，有些研发实验过程就需要较长周期，对于结果的分析等还需要时间。即便任务穿插起来，也难以做到天天有进展。我们研究所是以周例会的方式审查进度，有时仍感无明显进展。

我觉得研发管理从管理者的角度来讲，应该着重于重要节点的推进，必要时进行过程干预。而研发人员应该每周或者每天安排事项。的确如楼主所言，偏于技术应用的这类研发往往会有诸多杂事需要处理，但并不是事事都要领导或管理者去干预的。

不会发图

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

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

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

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

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

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

如果只关注目标，会导致盲目，找不到问题根源。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对整个研发过程不断产生的新的创意点子，如何管理呢？

应该定期讨论新的点子,并推动他们在漏斗中移动.

LZ把我的胃口吊得好高，我要干货干货！

方便举些实例来讨论吗？