9.28~30号飞音在上海召开了研发中期总结会，通过会议讨论，我们重新梳理了研发各部门下半年工作目标，飞音软硬件的技术发展路线，以及人员安排的考虑。通过本次会议，我发现有几方面的思想认识还是非常有必要再澄清强调一下。

　　一、怎么看待研发的工作目标与公司目标之间的关系
　　在召开研发中期总结会的前一个周末（即9.20~23），飞音在深圳召开了营销中期总结会，对营销目标做了一些调整。从营收角度看，飞音F2019的目标非常简单：实现营收翻翻！这一目标又具体落实到三条产品线（FTA/FGW，FWR和FIP）和三个销售组（大客户，国内渠道，国际渠道）上去。

　　那按照我想，既然营销在中期会议上已经对F2019H2完成营收任务所需要的产品和技术支持提出了明确的期望，研发部门的F2019H2安排当然应当对营销部门的期望有明确的回答，甚至于我们F2019H2的工作核心就是围绕满足营销部门的期望而展开的（注：所谓营销部门的期望，也即我们当前所认识到的市场和客户的期望）。

　　但实际上，大部分的研发总监/经理还没有建立这个意识，在F2019H2计划的第一版讨论中，并没有落实对营销期望的响应。所以，我认为首先有必要再次强调一下目标制定的S.M.A.R.T原则，其中的“R”就是指的Relevant，相关性。（注：关于S.M.A.R.T的详细解释参见《036.  搬砖与盖教堂》）另外，我也在反思如何把目标和S.M.A.R.T的思想彻底贯彻下去？也许从“飞音管理委员会”周例会的讨论形式做一定的调整是个好主意。

　　在创立飞音前，我有十年的工程师和研发管理经历。到今天，我一些底层的思维模式仍旧是工程师式的。客观的讲，工程师评价自己的劳动成绩时喜欢“就事论事”，喜欢“讲苦劳”。

　　这个倾向不光工程师有，研发经理也有；不光别人有，我做工程师的前几年也这么想。

　　举个例子，我刚毕业时曾经在一家做打印机的公司就职，做工程师。在当时我力主立项了一个采用菲利普16位单片机和uC-OS操作系统开发打印机主板的项目。这公司之前主要是用8051单片机和汇编语言开发，我不仅把CPU升级到16位，把开发语言换成C，还引入了实时操作系统—— 要知道，那可是1997年，挺牛X吧？

　　但这个项目最终并没有走到量产，也就是没有创造经济效益。有几方面的原因：（1）对这家公司的产品来说，16位单片机和RTOS并非必要，采用了也不能带来功能、性能和品质的明显提升，反而推高了成本；（2）这家公司在打印机方面多年积累了很多经验，但都是在8051和汇编平台上。用新平台做出DEMO很容易，但要产品化就要把过去“吃亏攒下的经验”逐一落实到新平台上，这件工作可相当浩大，我一个人可完不成，而要求其他工程师参与，就要求所有人学习新技能——培训就是个不菲的成本，更何况很多工程师干脆就宁可辞职也不愿学，研发组织成本高昂。

　　事后我想，这项目之所以立项，也反映了当时这家公司研发领导可爱的一面—— 由于这个公司是一家大学附属企业，研发的主要领导也在大学里有教授或副教授的职称，可能是出于对我探索新知识的支持而同意立项，但从公司管理角度看，这个批准是不合格的。

　　而我当时关注的也不过是学些新知识，做些新东西。至于公司的目标和发展，那和我有啥关系？所以当时这产品做出来，还觉得自己还挺牛的，不能量产也觉得是公司魄力不足，关我什么事？后来干脆辞职去了华为了事。

　　前几天碰到个也在这家公司工作过的朋友聊天，得知这公司终于在几年前倒闭了，感觉不胜唏嘘！回想起来，这公司的领导真是一帮很好的人，而我也确实有愧—— 在这公司时没做出啥靠谱的成绩，对不起我的工资。

　　但现在我做飞音，就绝不可以重蹈覆辙！所以我们要明确对“研发部门工作做的怎么样？”的评价标准：

　　这两个指标其实是互为表里，相互依存的。产品研发（主要的指标）完成不好，公司的营收上不去，就没有办法更大的投入研发。技术积累（次要的指标）完成不好，就不能有效的组织和调度资源，实现1+1大于2的效果，只会越做越累，终有一天将导致产品研发崩盘。

　　那么，再进一步，怎么具体的评价“我们的研发队伍培养的如何？”呢？我们放在下一节进一步讨论。

　　“飞音就靠三本书”之一的《精益创业》广泛而充分的讨论了“开发错了产品才是最大的低效和浪费”，并受“丰田方法”的启发，提出了“快速试错”的“精益”产品开发模式。

　　但是不是产品方向没问题，研发组织就是有效率的了呢？

　　当然不是的！要非常明确，研发组织的工作效率绝不是看“是否每个人都在忙”，或者“是否每个人都在高效率的忙”。研发组织的总效率也不等于个人效率的加总。

　　那怎么评估研发的效率呢？其实也是看上面两个指标：

　　前文说了，技术积累有两个维度：（1）原始设计文件（代码，典型电路库）和文档的积累；（2）研发队伍的培养。我们再具体说说研发队伍的培养。

　　“组织”和“骨干”也是互为表里，相互依存的。没有骨干，就很难搭建研发“组织”（选不出主管）；而没有“组织”也很难培养“骨干”——很难想象没有长期发展规划的工程师会成长成为骨干。

　　但非常遗憾的是，我发现很多研发总监/经理都特别喜欢“微操”。即便有十几个下属也不愿意分组，美其名曰“扁平化管理”，每天就指挥着下属你干干这，他干干那。每个工程师往往只知道最近几天或最近一两周的工作安排，自己的工作目标是什么？不知道。长期而言，公司期望自己成长为什么样的工程师？也不知道。感觉每天就是四处“救火”或“打杂”。这样组织研发，怎么可能获得高效的研发组织和优秀的研发骨干？

　　为什么会如此呢？可能是由于大部分研发系统的领导都是“技而优则仕”，他们都是很好的工程师，但对管理的理解则可能有失偏颇。下一节，我们来讨论下“研发总监的主要工作是什么？”

　　我曾经在“飞音管理培训课”介绍过，有位叫法约尔的管理大师在其经典着作《工业管理与一般管理》明确提出了五大管理职责，即：计划、组织、指挥、协调和控制。

　　所谓“微操”，无非是对“指挥、协调和控制”关注的过多，而对“计划、组织”关注的不够。其中，特别是对“组织”关注的不够。

　　那么，为什么工程师出身的研发经理往往会对“组织”关注不够呢？我猜想，很可能跟没有及时把自己的定位由“内聚”转变为“外延”有关。关于这事，最好的比喻说明是画个圈，如下图：

　　你可以把这个圈看作整个公司研发的“能力圈”，在升任研发总监/经理之前，主要关注的是“自己冲在一线是把能力圈之内的事情做好”。（注：各公司对领导层级定义不同，飞音目前只分为：工程师—主管—总监/经理，三个层级）而升任研发总监/经理之后则应该对内关注的是如何打造有力的研发“组织”让下属就能替代自己做好能力圈之内的事；对外关注的是 “如何扩展我们的能力圈”。比如，关注相关领域新技术的进展，关注竞争对手新技术和研发的进展，研究可以引入哪些新技术、新芯片、新开源项目以增强我们的能力圈等。

　　在《028. 在飞音如何做事？》这篇文章里，我介绍了飞音know what – know how – know why – know where 的职业资格/能力分级体系。那么，对软件部门来说，怎么定义初级，中级和高级工程师呢？在上海的F2019年中总结会上，我们提出如下分类，供大家参考：