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

有料哦~~~

看样子楼主还有下文，欢迎分享和讨论。

我就是在一家国企的研究院里，我公司门口挂的牌子就是某某技术中心。以前从来没思考过技术中心和研发中心的区别，经过您这么一点拨，觉得还真是有差别。我总觉得我们这样的老国企，有的是技术实力，科研实力实在是不敢恭维。

从来没有考虑过这个名词的含义，私企嘛，肯定不会做基础研究的。。往往山寨就算是创新了。。

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

（任务工作量由沪组长根据经验确定，以周记）

该示例中，有两个点需要说明。

第一是工作量的计算。笔者采用的组长的主管判断。即组长判断一个任务需要多长时间完成。这与该任务事实多长时间完成没有关系。其实就是组长给一个任务打分。而这种打分方式是比较简单易行的。其他任何企图量化任务量的努力，常常被发现不反应实际。而团队领导自己的感受，也许是最合适的。

第二是项目归属。这在项目组合管理的时候会讨论。