主题：【原创】中国式研发管理 -- ericyu
笔者是一个在欧美传统工业企业工作的中国研发管理人员。希望可以分享自己的工作经验，和同业们交流提高。这些经验是完全基于笔者的个人感受，而且由于缺乏系统的管理学培训，这些经验可能是偏颇的。但是，这些经验的确是实用的，在工作实践中得到实验的，是否适用于不同的工业不同的人群，不得而知。不过，大家如果能体会背后的目的，也许多少有所启发。
在中国，随着经济发展以及经济结构调整的需要，商业机构研发部门的建设正成为一个红火的运动。这个运动得到了政府，商业机构，用户群体的支持。甚至也得到了做为竞争对手的科研院校的支持。
科研院校一直以来是中国的科研主体，他们并不认为商业机构的研发部门对其构成了任何的冲击。相反其相信院校的各种知识产品，包括专利技术，实验服务以及学生培养，将得到更多的顾客。的确在越来越多的商业研发机构开张以来，这种合作关系取得急速的发展。
而正因为这种合作关系，相当多的商业研发机构或多或少采用了中国科研院校尤其是大学的科研文化甚至体制。至少，当许多研发机构被从大学培养出的博士们领导时，这种影响是不可避免的。于是，无论洋博士还是土博士领导的研发团队，是随处可见的。如果他们还采用大学科研体制以及文化，成功的案例不多。常见的评价就是：“太理论化”，“不够贴近实际”，等等。
有看客会问，那还有什么其他的途径在中国建立商业机构研发体制吗？当然是有的。第一是模仿发达国家，特别是外资企业和以IT为主的高科技行业。其次则是传自国企。奇特的是，两条道路在中国某种程度上合流到了一个结果：商业研发机构很快蜕变成了企业技术中心。
研发中心与技术中心有什么区别？在这里笔者不谈实质内容，只涉及体制和文化。研发中心的基础是创新文化，所以体制上必然是有许多现代管理内容。在笔者看来，主要是项目化管理和在此基础上的项目组合管理。而技术中心的文化是应用和及时反应，强调的是效率和速度。当然两者区别不是黑与白，更加不是取决于门口挂的是那块匾；一个机构如果更偏向创新与项目化，就是一个更“研发”的团队；而反之，如果更偏向效率和日常管理，就是一个更“技术部”的团队。
在中国建立研发机构，外资企业半心半意，不愿意将长期的核心的项目放在中国。往往他们更看重通过该机构更好的服务客户，收集客户对新技术的反馈，所以极其容易变成一个技术应用中心。这些研发机构所从事的项目，往往是典型的应用型项目，或者是本地开发型项目，很难有战略性的长期新技术项目。
而新建研发机构的民族企业，大部分是私人企业。老板很快会发现，要利用好自己的研发机构，就是将其建设为技术应用中心。大多数民族企业对于需要大投入长回报的战略开发，还是依赖于山寨和购买。
当然我们国家的老国企，例如航天航空，高铁制造，一定是有其成熟成功的研发机构。但是这些机构并非“新”机构。不在笔者讨论范围之列。他们是否也需要借鉴本文的经验，只能是见仁见智了。
所以本文是立足于以上的个人认识，为当今在中国的新建商业研发机构提供一个样本来参考。我相信其中大多数经验是实际的有用的。至于当今研发机构现状是否会发生改变，这是不可预知的未来。如果没有显著的外围环境变化，笔者看不到现状改变的可能。
有料哦~~~
看样子楼主还有下文，欢迎分享和讨论。
我就是在一家国企的研究院里，我公司门口挂的牌子就是某某技术中心。以前从来没思考过技术中心和研发中心的区别，经过您这么一点拨，觉得还真是有差别。我总觉得我们这样的老国企，有的是技术实力，科研实力实在是不敢恭维。
从来没有考虑过这个名词的含义，私企嘛，肯定不会做基础研究的。。往往山寨就算是创新了。。
如我所言，在中国的新建商业研发机构，采取偏技术应用中心模式是更贴近实际的。这就意味着，实时的日常的任务管理比长期的项目管理，对研发管理人员来说更重要。据笔者观察，即使在我所在的偏研发体制的机构里，日常内容也要占到一半的资源。如果是完全贴近生产部门的技术中心，更是几乎100%的是日常内容。
研发任务管理，如同所有的管理一样，没有特殊之处。就是列出团队成员的任务，规定交期，考察完成情况。而且如同其他管理，任务管理，应该是以“日”为单位的。每天团队领导都必须和成员讨论他们的工作任务。
有看客会提出，对研发从业人员进行以“日”为单位的管理，是太落后了。在中国，由于人力资源市场的极度活跃，研发从业人员往往年轻，缺乏经验。又或者，由于我国分配体制及社会保障体制的不完善，造成了工作人员的职业道德普遍不高，无法为内在驱动而努力工作。进而言之，即使发达国家的工作人员，也未见得就是个个职业道德高尚，为公司倾尽所有。人的惰性是天然的，这正是管理存在的必要性。正面的挑战人性的自大和懒惰，是任务管理的目的。
也许对以一个管理数十人的研发机构老总来说，进行以日为单位的任务管理是不必要的。但是老总们必须建立起以日为单位的任务管理模式，要求某些必要的下属遵循。建立在这种模式上的效率分析，更是老总们掌握你的机构必须的工具。
基础研究还是应该归公共平台，如高校和国家科研院所。只是我国的公共平台受到商业平台的制约太少。
为了更好的描述笔者的经验，我必须举一个例子。而为了保密，我无法使用工作中的例子。而且笔者的工作内容，也许不容易为所有人理解。所以我试图创造一个简单易懂的例子。那么我假设一个奶茶连锁店的研发中心。在本文中，我们将管理这个中心。
假设该中心有一个团队，专门为上海地区的20家连锁店提供技术服务。该团队有3位同事，分别是负责配方的沪甲，负责设备的沪乙和负责客户体验的沪丙。团队负责人是沪组长。
沪组长必须对该团队的任务分类。方法有许多种。以下是笔者考虑过的方法：
1) 按内容划分为四类：配方，设备，客户体验以及团队发展。这里看客也许有两个问题：
a) 为什么要有团队发展？这是非常重要的分类。首先，团队领导的任务一定要在分类中表现出来，也可以取名为“团队管理”。对以研发团队，透明度和民主性是很重要的领导力元素，不可轻视。其次，团队必然有一些无法分类的任务，如果取名为“其他”，不是最好的名字。所以“团队发展”是个不错的名字。而且与其把领导任务划为“管理”，不如归到“发展”更亲民。
b) 如果团队成员有明确分工了，为何还要按内容划分？不如用各自的名字更直截了当。事实上，许多管理人员正是采取的这种方法。但按人划分的分类方法，对研发团队是极其不合适的。首先，研发团队一定要强调能力的全面发展，按人划分就画地为牢了。其次，技术工作往往无法分割。例如配方的技术问题，常常离不开特定的设备情况，于是研究配方的任务，必不可免涉及设备。一项任务开始时分为以配方研究为主，而随着任务发展，也许成为设备研究。这时不是都可以简单的将该项任务从沪甲负责转为沪乙负责的。所以任务还是要以内容分为好。而且任何分类衡量的应该是团队效率而不是某个人的成绩。
2) 按项目管理的关卡模型分类：点子，可行性，项目，应用等等。这种分类法将在介绍项目管理时再讨论。
3) 按任务所属操作步骤分类：备料，混合，加热，包装。这种分类往往是应用于有着明显操作步骤的大工业，或者如药物研发的合成步骤等。
4) 按任务属性分类：实验室模拟，仪器分析，文献检索，客户调查，等等
笔者大部分时间使用按内容分类。这也是大多数人的自然选择。因为这是最直观，而且往往是与团队成员挂钩最直接的方式。不足点在于，这种分类方式下的各项任务，其所需工作量是不直观的。属于某项内容的任务们可能是只要一天的，也可能是要一月的。工作量的评价往往是非常主观的。按任务所属操作步骤分类的优缺点基本与按内容分类接近。
笔者也在内容分类里包括了按任务属性分类的任务。这些任务的工作量相对容易衡量。其后，我们建立了完全以属性为基础的任务清单，便于团队效率管理。不足点在于，这种清单是离内容最远的方式。如果只是阅览清单，你无法得到该团队所从事的重点。
按项目管理的关卡模型分类，可以同时了解技术内容和衡量团队效率。但是这是一个过于复杂的清单。对于管理的工作负担要求较高。事实上，管理人员在使用管理项目的方式管理每天的任务。所以除非是很有必要或者初入门的研发管理人员为了练手，最好避免简单问题复杂化，不要使用这种方式。
很有启发意义
在私企做研发，技术应用中心的定位是比较准确的。
本人也是。大环境决定了高层管理的视野和目标，也就产生了限制和导向。理想的自主驱动疯狂野蛮生长的环境是个特例
这个一点也不落后，近些年大行其道的“敏捷开发”的一个核心内容，就是每一天都会举行项目状况会议，被称为“scrum meeting”或“每日站立会议”。每日站立会议有一些具体的指导原则：
会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有"猪"可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：
今天你完成了哪些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
“猪”是全身投入项目和Scrum过程的人： they are the ones with "their bacon on the line."
好文章，期待持续更新
以下是任务清单的示例，假设这是Excel中的一个Sheet，记录的是一个月的配方研究的任务。
完成的工作量 任务 负责人 附注 所属项目
1 任务一 沪甲 P201201
1.5 任务二 沪甲 P201201
0.5 任务三 沪甲 P201200
1 任务四 沪乙 P201200
1 任务五 沪组长 P201200
5 当月统计
（任务工作量由沪组长根据经验确定，以周记）
该示例中，有两个点需要说明。
第一是工作量的计算。笔者采用的组长的主管判断。即组长判断一个任务需要多长时间完成。这与该任务事实多长时间完成没有关系。其实就是组长给一个任务打分。而这种打分方式是比较简单易行的。其他任何企图量化任务量的努力，常常被发现不反应实际。而团队领导自己的感受，也许是最合适的。
第二是项目归属。这在项目组合管理的时候会讨论。